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PREFACE 


This manual consists of two parts: 


1. An Introduction, describing the FOR- 
TRAN IV (H) compiler as ae whole, 
including its relationship to the 
operating system. The major compo- 
nents of the compiler and the rela- 
tionships among them are aliso de- 
scribed. 


2. A Body, containing a description of 
each component. Each component is 
discussed in terms of the functions it 
performs and the level of detail pro- 
vided is sufficient to enable the 
reader to understand the general oper- 
ation of the component. In the dis- 
cussion of each function of a compo- 
nent, the routines that implement that 


function are identified by name. The 
inclusion of the routine names _ pro- 
vides a frame of reference for the 
comments and coding supplied in the 


program listing. The program listing 
for each identified routine appears on 
the microfiche card having the name of 
that routine in its heading. This 
section also discusses common data, 
such as tables, biocks, and work 
areas, but only to the extent required 
to understand the logic of the compo- 
nents. Flowcharts and routine direc- 
tories are included at the end of this 
section. 


Following the second part are a number 
of appendixes, which contain reference 
material. 

LE more detailed information is 


required, the reader should refer to the 
comments, remarks, and coding in the FOR- 
TRAN IV (H) program listing. 
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This section contains general informa- 
tion describing the purpose of the FORTRAN 
Iv (H) compiler, its relationship to the 
operating system, its input/output data 
flow, its organization, and its structure. 


PURPOSE OF THE COMPILER 


The IBM System/360 Operating System FOR- 
TRAN IV (H) compiler transforms source 
modules written in the FORTRAN IV language 
into object modules that are suitable for 
input to the linkage editor for subsequent 
execution on the System/360. At the user's 
option, the compiler produces optimized 
object modules (modules that can be execut- 
ed with improved efficiency). 


THE COMPILER AND OPERATING SYSTEM/360 


The FORTRAN IV (H) compiler is a proc- 


essing program which communicates with the. 


System/360 Operating System control program 
for input/output and other services. A 
general description of the control program 
is given in the publication IBM System/360 
Operating System: Introduction to Control 


Program Logic, Program Logic Manual. 


A compilation, Or a batch of compila- 
tions, is requested using the job statement 
(JOB), the execute statement (EXEC), and 
data definition statements (DD). Aiterna- 
tively, cataloged procedures may be used. 
A discussion of FORTRAN IV compilation and 
the available cataloged procedures is given 


in the publication IBM System/360 Operating 
System: FORTRAN IV Programmer's Guide. 


The compiler receives control from the 
calling program (e.g., job scheduler or 
another program that calls, links to, or 
attaches the compiler). Once the compiler 
receives control, it communicates with the 
control program through the FORTRAN system 
director, a part of the compiler that 
controls compiler processing. After com- 
piler processing is completed, control is 
returned to the operating system. 


INPUT/OUTPUT DATA FLOW 


The source modules to be compiled are 
read in from the SYSIN data set. Compiler 
output is placed on the SYSLIN, SYSPRINT, 
SYSPUNCH, or SYSUT1 data set, depending on 
the options specified by the FORTRAN pro- 
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grammer. (The SYSPRINT data set is always 
required for compilation.) 


The overall data flow and the data sets 
used for the compilation are illustrated in 
Figure 1. 


COMPILER ORGANIZATION 


The IBM System/360 Operating System FOR- 
TRAN IV (H) compiler consists of the FOR- 
TRAN system director, four logical process- 
ing phases (phases 10, 15, 20, and 25), ana 
an error-handling phase (phase30). 


Control is passed among the phases of 
the compiler via the FORTRAN system direc- 
tor. After each phase has been executed, 
the FORTRAN system director determines the 
next phase to be executed, and calls that 
phase. The flow of control within the 
compiler is illustrated in Chart 00. 


The components of the compiler operating 
together produce an object module from a 


FORTRAN source module. The object module 
is acceptable as input to the linkage 
editor, which prepares object inodules for 


relocatable loading and execution. 


The object module consists of control 
dictionaries (external symbol dictionary 
and relocation dictionary), text 
(representing the actual machine instruc- 
tions and data), and an END statement. The 
external symbol dictionary (ESD) contains 
the external symbols that have been defined 
or referred to in the source module. The 
relocation dictionary (RLD) contains infor- 
mation about address constants in the 


object module. 


The functions 
compiler are 
paragraphs. 


of the components of the 
described in the following 


FORTRAN SYSTEM DIRECTOR 


The FORTRAN system director (FSD) con- 
trols compiler processing. It initializes 
compiler operation, calls the phases for 
execution, and distributes and keeps track 
of the main storage used during the compi- 
lation. In addition, the FSD receives the 
various input/output requests of the com- 
piler phases and submits them to the con- 
trol program. 


Section 1: Introduction 11 


SYSIN 


Source 
Module (s) 
FORTRAN IV 
(H) Compiler 












SOURCE EDIT MAP 
Option 








Option 








LOAD 
Option 





DECK LIST 
Option 


For All 








Option 


Compilations 





‘ Object Module Object Module ; Error and 
cE. Intermediate Storage (ESD, TXT, (ESD, TXT, Object Warning 
ule Output Ma END Program ‘A 
Listing for EDIT p RLD, and END RLD, and Listing essages 
card images) card images) (If Any) 
SYSPRINT SYSUT] SYSPRINT SYSLIN SYSPUNCH SYSPRINT SYSPRINT 
Structured 
Source 
Listing 
SYSPRINT 
Figure 1. Input/Output Data Flow 
PHASE 10 ed into three segments that perform the 
following functions: 
Phase 10 accepts as input (from the 
SYSIN data set) the individual source e The first segment adds data _ to the 
Statements of the source module. If a information table about COMMON and 
source module listing is requested, the EQUIVALENCE statements so that main 


source statements are recorded on the 
SYSPRINT data set. If the EDIT option is 
selected, the source statements are record- 
ed on the SYSUT1 data set, which phase 20 
uses aS input to produce ae structured 
source listing. Phase 10 converts each 
source statement into a form usable as 
input by succeeding phases. This usable 
input consists of an intermediate text 
representation (in operator-operand pair 
format) of each source statement. In addi- 
tion, phase 10 makes entries in an informa- 
tion table for the variables, constants, 
literals, statement numbers, etc., that 
appear in the source statements. During 
this conversion process, phase 10 also 
analyzes the source statements for syntac- 
tical errors. If errors are encountered, 
phase 10 passes to phase 30 (by making 
entries in the error table) the information 
needed to print the appropriate error mes- 
sages. 


PHASE 15 


Phase 15 gathers additional information 


about the source module and modifies some 
intermediate text entries to facilitate 
optimization by phase 20 and instruction 


generation by phase 25. Phase 15 is divid- 


L2 


storage space can be allocated correct- 
ly in the object module. 


e The next segment translates text 
entries (in operator-operand pair 
format) representing arithmetic opera- 


tions into a four-part form, which is 
needed for optimization by phase 20 and 
instruction-generation by phase 25: 


This part of phase 15 also gathers 
information about the source module 
that is needed for optimization by 
phase 20. 


e The last segment of phase 15 assigns 
relative addresses, and where neces- 
sary, address constants to the named 
variables and constants in the source 
module. This segment aiso converts 
intermediate text (in operator-operand 
pair format) representing DATA state- 
ments to a variable-initial value forn, 
which facilitates later assignment of a 
constant value to a variable. In addi- 
tion, this segment produces a storage 
imap if the MAP option is specified. 


Phase 15 also passes to phase 30 the 
information needed to print the appropriate 
messages for the errors detected during 
phase 15 processing. (This is done by 
Making entries in the error table.) 


PHASE 20 


Phase 20 processing depends on whether 
or not optimization has been requested and, 
if so, the degree of optimization desired. 


If optimization has not been specified, 
phase 20 assigns registers for use during 
-execution of the object module. However, 
phase 20 does not take full advantage of 
all registers and makes no effort to keep 
frequently used quantities in registers to 
eliminate the need for some machine 
instructions. 


If a moderate amount of optimization is 
Specified, phase 20 uses all available 
registers and keeps frequently used quanti- 
ties in registers wherever possible. Phase 
20 takes other measures to reduce the size 
of the object module, and provides informa- 
tion about operands to phase 25. 


If complete optimization has been speci- 
fied, phase 20 uses other techniques to 
make a more efficient object module. The 
net result of these procedures is to elimi- 
nate unnecessary instructions and to elimi- 
nate needless execution of instructions. 


During processing, phase 20 records 
directly on the SYSPRINT data set messages 
describing any errors it detects and, if 
both the EDIT option and complete optimiza- 
tion are selected, produces, on the SYS- 
PRINT data set, a structured source program 
listing. 


PHASE 25 
Phase 25 produces an object module from 
the combined output of the preceding phases 


of the compiler. 


The text information (instructions and 
data resulting from the compilation) is in 


a relocatable machine language form. It 
May contain unresolved external symbolic 
cross references (i.e., references to sym- 
bols that do not appear in the source 
module). The external symbol dictionary 
contains the information required by the 
linkage editor to resolve external symbolic 
cross references, and the relocation dic- 
tionary contains the information needed by 
the linkage editor to relocate the text 
information. 


Phase 25 places the object module 
resulting from the compilation on the SYS- 
LIN data set if the LOAD option is’ speci- 
fied, and on the SYSPUNCH data set if the 
DECK option is specified. Phase 25 also 
produces an object module listing on the 
SYSPRINT data set if the LIST option is 
specified. Messages for any errors detect- 
ed during phase 25 processing are also 
recorded directly on SYSPRINT. 


PHASE 30 

Phase 30 is called after phase 15 proc- 
essing is completed only if errors are 
detected by phases 10 or 15. Phase 30 


records on the SYSPRINT data set messages 
describing the detected errors. 


STRUCTURE OF THE COMPILER 


The FORTRAN IV (BH) 
tured in 


compiler is struc- 
a planned overlay fashion, whicn 


consists of 20 segments. Two of these 
segments constitute the FORTRAN system 
director. The largest of these two seg- 
ments is the root segment of the planned 
overlay structure. Each of the remaining 
18 segments constitutes a phase or a_ logi- 
cal portion of a phase. A detailed discus- 
sion of the compiler's planned cverlay 


structure is given in Appendix G. 
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SECTION 2; DISCUSSION OF MAJOR COMPONENTS 


The following paragraphs and associated 
flowcharts at the end of this’ section 
describe the major components of the FOR- 
TRAN IV (H) compiler. Each component is 
described to the extent necessary to 
explain its function(s) and general opera- 
tion. 


FORTRAN SYSTEM DIRECTOR 


The FORTRAN System Director (FSD) con- 
trols compiler processing; its overall 
logic is illustrated in Chart 01. The FSD 
receives control from the job scheduler if 
the compilation is defined as a job step in 
an EXEC statement. The FSD may aiso 
receive control from another program 
through use of one of the system macro- 
instructions (CALL, LINK, or ATTACH). 


The FSD performs compiler initial- 
ization, phase loading, storage 
distribution (including storage inventory), 
input/output request processing, compila- 
tion deletion, and compiler termination. 


COMPILER INITIALIZATION 


The initialization of compiler process- 
ing by the FSD consists of two steps: 


e Parameter processing. 
e Data field initialization. 


Parameter Processing 


When the FSD iS given control, the 
address of a parameter list is contained in 
a general register. If the compiler 
receives control as a result of either an 
EXEC statement in a job step or an ATTACH 
or CALL macro-instruction in another pro- 
gram, the parameter list has ae single 
entry, which is a pointer to the main 
storage area containing an image of the 
options (e.g., SOURCE, MAP) specified for 
the compilation. If the compiler receives 
control as a result of a LINK macro- 
instruction in another program, the param- 
eter list may have a second entry, which is 
a pointer to the main storage area contain- 
ing substitute ddnames (i.e., ddnames that 
the user wishes to substitute for the 
standard ones of SYSIN, SYSPRINT, SYSPUNCH, 
SYSLIN, and SYSUT1). 


COMPILER OPTIONS: To determine the options 
specified for the compilation and to inform 
the various compiler phases of these 
options, the FSD scans and analyzes the 
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storage area containing their images and 
sets indicators to reflect the ones. speci- 
fied. These indicators are placed into the 
communication table (refer to Appendix A, 
"Communication Table") during data field 
initialization. The various compiler phas- 
es have access to the communication table, 
and, from the indicators contained in it, 
can determine which options have been 
selected for the compilation. 


If the user wishes to 
substitute ddnames for the standard ones, 
the FSD must establish a correspondence 
between the DD statements having the _ sub- 
Stitute ddnames and the DCBs (Data Control 
Blocks) associated with the ddnames to be 
replaced. To establish this necessary cor- 
respondence, the FSD scans the storage area 
containing the substitute ddnames, and 
enters each such ddname into the DCBDDNM 
field of the DCB associated with the stan- 
dard ddname it is to replace. 


SUBSTITUTE DDNAMES: 


Data Field Initialization 


Data field initialization is concerned 
with the communication table, which is a 
central gathering area used to communicate 
information among the phases of the compil- 
er. It contains information such as: 


e User specified options. 


e Pointers indicating the next available 
locations within the various storage 
areas. 


e Pointers to the initial entries in the 


various types of chains (refer to 
Appendix A, “Information Tabie™ and 
Appendix B, “Intermediate Text"). 

e Name of the source. module being com- 


piled. 


e® An indication of the phase currently in 
control. 


The various fields of the communication 
table, which are filled during a compila- 
tion, must be initialized before the next 
compilation. To initialize this region, 


the FSD clears it and places the option 
indicators into the fields reserved for 
them. 


PHASE LOADING 


The FSD loads and passes control to each 
phase of the compiler by means of a stan- 


dard calling sequence. The execution of 
the call causes control to be passed to the 
overlay supervisor, which calis program 
fetch to read in the phase. Control is 
then returned to the overlay supervisor, 
which branches to the phase. The phases 
are called for execution in the following 
sequence: phase 10, phase 15, phase 20, and 
phase 25. However, if errors are detected 
by phase 10 or phase 15, phase 30 is called 
after the completion of phase 15 process- 
ing. , 


STORAGE DISTRIBUTION 


Phases 10, 15, and 20 require main 
storage space in which to construct the 
information table (refer to Appendix A, 
"Information Table") and to collect inter- 
mediate text entries. These phases obtain 
this storage space by submitting requests 
to the FSD (at entry point GETCOR), which 
allocates the required space, if available, 
and returns to the requesting phase point- 
ers to both the beginning and end of the 
allocated storage space. If main storage 
Space is not available, the FSD deletes the 
compilation. 


The main storage space available for 
building the information table or for col- 
lecting text entries is assembled into the 
FSD in the form of define storage (DS) 
Statements. The distribution of the avail- 
able storage by the FSD depends upon the 
phase requesting the storage. For this 
reason, the remainder of this discussion is 
divided into three parts: the first relat- 
ing to phase 10, the second to phase 15, 
and the third to phase 20. 


Phase 10 Storage 


Phase 10 can use all of the available 
storage space for building the information 
table and for collecting text entries. At 
first, the FSD presents the entire block of 
available main storage space to phase 10 
for use in building the information table. 
At each phase 10 request for main storage 
in which to collect text entries, the FSD 
reallocates a portion (i.e., a sub-block) 
of the storage (first allocated to the 
information table) for text collection, and 
returns to phase 10 either via the communi- 
cation table or the storage area P10A 
(depending upon the type of text to be 
collected in the sub-block; refer to Appen- 
dix B, “Phase 10 Intermediate Text") point- 
ers to both the beginning and end of the 
allocated storage space. If the sub-block 
is allocated for phase 10 normal text, the 
pointers are returned in the communication 
table. If the sub-block is allocated for a 
phase 10 text type other than normal text, 
the pointers are returned via the storage 
area P10A. After the storage has been 
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allocated, the FSD adjusts the end of the 
information table downward by the size of 
the allocated sub-block. This process is 
repeated for each phase 10 request for main 
storage space in which to collect text 
entries. (If the last information table 
entry and the sub-block to be allocated for 
text collection would overlap, the avail- 
able storage is split, with one part being 
allocated for building the information 
table and the other for collecting text 
entries.) 


The size of each sub-bliock allocated for 
the collection of phase 10 text entries 


depends upon the type of the text entries 
that are to be placed into the sub-block. 
All sub-blocks allocated to contain the 
Same type of phase 10 text entries are of 
the same size. 

Sub-blocks to contain phase 10 text 


entries are allocated in the order in which 
requests for main storage are received. 
(When phase 10 completely fills one sub- 
block with text entries, it requests 
another.) A request for a sub-block to 
contain a particular type of text entries 
May immediately follow a request for a 
sub-block to contain another type of text 
entries. Consequently, sub-blocks allocat- 
ed to contain the same type of text entries 
may be scattered throughout main storage. 


The FSD must keep track of the sub-blocks 
so that, at the completion of phase 10 
processing, unused or unnecessary storage 


may be allocated to phase 15. The manner 
in which the FSD keeps track of sub-pbiocks 
allocated to phase 10 is described in the 
following paragraph. 


Phase 10 Storage Inventory: The FSD 
employs a pointer table and chains (see 
Figure 2) to keep track of the sub-blocks 
allocated for phase 10 text entries. If 
the sub-block allocated is the first to be 
used for the collection of a particular 
type of phase 10 text, the FSD places a 
pointer to that sub-block into the pointer 
table. After the initial link is estab- 
lished, the size of the sub-block is placed 
into the sub-block itself. If a second 
sub-block is allocated for the same _ pur- 
pose, the FSD places a pointer to it into 
the first word of the first sub-biock 
allocated for that purpose. The size of 
the sub-block is then placed into the 
sub-block itself. If a third sub-biock is 
allocated for the same -purpese, -the-.-same 
procedure is followed, with a pointer to 
the third sub-block being placed into the 
first word of the second sub-block. Figure 
2 illustrates this concept as applied to 
sub-blocks allocated to contain phase 10 
normal, SF skeleton, and data text. (The 
pointer field of the last sub-block of each 
type is always zero.) 
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Figure 2. 


Phase 15 Storage 


Current end of information table storage, which may 
float downward if additional storage is required by phase 
10 for text collection. 


Storage Inventory for Phase 10 Normal, 


Phase 15, in collecting the text entries 


that it creates, can use only those _ por- 
tions of main storage that are (1) unused 
by phase 10, and (2) occupied by phase 10 
normal text entries that have been proc- 
essed by phase 15. The FSD first allocates 
all unused storage (if necessary) to phase 


15. If this is not sufficient, the FSD 
then aliocates the storage occupied by 
phase 10 normal text entries that have 


undergone phase 15 processing. 


The main storage not used by phase 10 
consists of: 


e The portion between the last sub-block 
allocated to phase 10 for text collec- 
tion and the end of the information 
table. 


e Those portions of the sub-blocks allo- 
cated to phase 10 that do not contain 
text entries. (The last sub-block 
allocated to each type of phase 10 text 
Iay not be completely filled.) 


After phase 10 processing is complete, 
the FSD splits the storage area between the 
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SF Skeleton, and Data Text 


last sub-block allocated to phase 10 and 
the last information table entry, allocates 
one part to the information table, and 
treats the as an unused text 
storage area. The individual portions of 
unused storage, excluding the portion allo- 
cated to the information table, are then 
chained together (see Figure 3). The first 
phase 15 request for storage for text 
collection is satisfied with the unused 
portion between the last sub-block allocat- 
ed to phase 10 and the end of the informa- 
tion table. Pointers to both the beginning 
and end of the storage are passed to phase 
15 via the communication table. Each sub- 
sequent phase 15 request for text area 
storage is satisfied with an unused portion 
of a phase 10 sub-block. (Sub-block por- 
tions are allocated in the order in which 
they are chained.) Pointers to both the 
beginning and end of the ailocated sub- 
block portion are passed to phase 15 via 
the communication table. If an additional 
request is received after the last sub- 
block portion is allocated, the FSD 
determines the last phase 10 normal text 
entry that was processed by phase 15. The 
FSD then frees and allocates to phase 15 


other part 


‘the portion of storage occupied by phase 10 


normal text entries between the first such 
text entry and the last entry processed by 
phase 15. 


Phase 15 Storage Inventory: After the 
processing of PHAZ15, the second segment of 


phase 15, is completed, the FSD recovers 
the sub-blocks that were allocated to phase 
10 normal and SF _ skeleton text. These 
sub-blocks are chained as extensions to the 
storage space 
of PHAZ15 processing. The chain, which 
begins in the FSD pointer table, connecting 
the various available portions of storage 
is scanned and when a zero pointer field is 
encountered, a pointer to the first sub- 
block allocated to phase 10 normal text is 
placed into that field. The chain 
connecting the various sub-blocks allocated 
to phase 10 normal text is then scanned and 
when a zero pointer field is encountered, a 
pointer to the first sub-block allocated to 
SF skeleton text is placed into that field. 
Once the sub-blocks are chained in this 
manner, they are available for allocation 
to CORAL, the third segment of phase 15, 
and to phase 20. 


After the processing of CORAL is com- 
pleted, the FSD likewise recovers the sub- 
blocks allocated for phase 10 data text. 
The chain connecting the various portions 
of available storage space is scanned and 
when a zero pointer field is encountered, a 
pointer to the first sub-block allocated 
for phase 10 data text is placed into that 
field. After the sub-blocks allocated for 
phase 10 data text are linked into the 
chain as described above, they, as well as 
all other portions of storage space in the 
chain, are available for allocation to 
phase 20. 


Completely Filled with Phase 10 Text Entries 





| Unused Portion of Sub-block 


| Unused Portion 
of Sub-block 
RIESE SE et 
_ : Unused Portion of Sub-block 


Unused Portion of Last Phase 
10 Sub-block (first sub-block 
portion allocated to phase 15) 


Available Storage 


Pointer 
FSD first allocates this portion of unused storage to 


phase 15. Sub-block portions are then allocated 
in the order in which they are chained together. 


| Pointer __| 


Information Table 


Start — 


available at the completion - 





Phase 20 Storage 


Each phase 20 request for storage space 


is satisfied with a portion of storage 
available at the completion of CORAL 
processing. The portions of storage are 


allocated to phase 20 in the order in which 
they are chained. Pointers to both the 
beginning and end to the storage allocated 
to phase 20 for each request are placed 
into the communication table. 


INPUT/OUTPUT REQUEST PROCESSING 


The FSD routine IEKFCOMH receives the 
input/output requests of the compiler phas- 
es and submits them to BSAM (Basic Sequen- 
tial Access Method) for implementation 


(refer to IBM System/360 Operating System: 


Sequential Access Methods, Program Logic 
Manual.) 


Request Format 


Phase reguests for input/output services 
are made in the form of READ/WRITE state- 
ments requiring a FORMAT statement. The 
format codes that can appear in the FORMAT 
statement associated with such READ/WRITE 
requests are a subset of those available in 
the FORTRAN IV language. The subset con- 
Sists of the following codes: Iw (output 
only), Tw, Aw, wX, wH, and Zw (output 
only). 


End of information table. 


*—— (Fixed after phase 10 processing.) 


Figure 3. Chaining of Unused Text Area Main Storage 
€ 


Section 2: 


Discussion of Major Components 17 


Request Processing 


To process input/output requests from 
the compiler phases, the FSD performs a 
series of operations, which are a subset of 
those carried out by the IHCFCOMH/IHCFIOSH 
combination (refer to Appendix E) to imple- 
ment sequential READ/WRITE statements 
requiring a format. 


DELETION OF A COMPILATION 


The FSD deletes a compilation if either 
of the following occurs: 


e An error of error level code 16 (refer 


to the publication IBM System/360 Oper- 


ating System: FORTRAN IV Programmer's 
Guide) is detected during the execution 


of a processing phase. 


e The value of the error level code 
returned from phase 30 is 8 and the 
LOAD option has not been specified. 

In the former case, the phase detecting 
the error passes control to the FSD at 
entry point SYSDIR. If the error was 
detected by phase 10, the FSD deletes the 
compilation by reading records (without 
processing them) until the END statement is 
encountered. It then initializes the com- 
piler for the next compilation. If the 
error was encountered in a phase other than 
phase 10, the FSD simply initializes the 
compiler for the next compilation. 


In the latter case, phase 30 returns 
control to the FSD at the next sequential 
instruction. If the error level code 
passed to the FSD is 8 and the LOAD option 
has not been specified, the FSD initializes 
the compiler for the next compilation. 


Note: Phase 25 returns an error level code 
of 8 to the FSD if errors are detected 
during the translation of FORMAT state- 
ments. However, in this case, the FSD does 
not delete the compilation if the LOAD 
option has not been specified. 


COMPILER TERMINATION 


The FSD terminates compiler processing 


when an end-of-file is encountered in the 
input data stream or when a permanent 
input/output error is encountered. If, 
after the deletion of a compilation or 
after a source module has been completely 


compiled, the first record read by phase 10 
from the SYSIN data set contains an end-of- 
file indicator, control is passed to the 
FSD (at the entry point ENDFILE), which 
terminates compiler processing by returning 
control to the operating system. If a 
permanent error is encountered during the 
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servicing of an input/output request of a 


phase, control is passed to the FSD (at 
entry point IBCOMRTN), which writes a 
message Stating that both the compilation 
and job step are deleted. The FSD then 
returns control to the operating system. 
In either of the above cases, the FSD 


passes to the operating system as a condi- 


tion code the value of the highest error 
level code encountered during compiler 
processing. The value of the code is used 


to determine whether or not the next job 
step is to be performed. 


PHASE 10 


Phase 10 converts each FORTRAN source 
statement into usable input to subsequent 
phases of the compiler; its overall logic 
is illustrated in Chart 03. Phase 10 
conversion produces an intermediate text 
representation of the source statement 
and/or detailed information describing the 
variables, constants, literals, statement 
numbers, data set reference numbers, etc., 
appearing in the source statement. During 
conversion, the source statement is ana- 
lyzed for syntactical errors. 
intermediate text is a 
internal representation (i.e., 
internal to the compiler) of a source 
statement. It is developed by scanning the 
source statement from left to right and by 
constructing operator-operand pairs. In 
this context, operator refers to such ele- 
ments as commas, parentheses, and slashes, 
as well as to arithmetic, relational, and 
logical operators. Operand refers to such 
elements as variables, constants, literals, 
statement numbers, and data set reference 
numbers. An operator-operand pair isa 
text entry, and all text entries for the 
operator-operand pairs of a source state- 
ment are the intermediate text representa- 
tion of that statement. 


The 
defined 


strictly 


There are five types of intermediate 
text developed by phase 10. They are: 
normal, data, namelist, format, and state- 
ment function (SF) skeleton. 


e Normal text is the intermediate text 
representation of source statements 


other than DATA, NAMELIST, FORMAT, and 
statement functions. 


e Data _ text is the intermediate text 
representation of DATA statements and 
initialization values in type state- 


ments. 


e Namelist text is the intermediate text 
representation of NAMELIST statements. 


e Format text is the intermediate text 
representation of FORMAT statements. 


e SF skeleton text is the intermediate 
text representation of statement func- 
tions using sequence numbers as _  oper- 
ands of the intermediate text entries. 
The sequence numbers replace the dummy 
arguments of the statement functions. 
This type of text is, in effect, a 
"skeleton" macro. 


The various text types are discussed in 
detail in Appendix B, "Intermediate Text." 


The detaiied information describing 
operands includes such facts as whether a 
variable is dimensioned (i.e., an array) 
and whether the elements of an array are 
real, integer, etc. Such information is 
entered into the information table. 


The information table consists of five 
components : dictionary, statement 
number/array table, common table, literal 
table, and branch table. 


e The dictionary contains information 
describing the constants and variables 
of the source module. 


e The statement  number/array table con- 
tains information describing the state- 


ment numbers and arrays of the source 
module. 
* The common table contains information 


describing COMMON and EQUIVALENCE dec- 
larations. 


e The Literal table contains information 
describing the literals of the source 
module. 


e The branch table contains information 
describing statement numbers appearing 
in computed GO TO statements. 


A detailed discussion of the information 
table is given in Appendix A, “Information 
Table." 


The intermediate text and the informa- 
tion table complement each other in the 
actual code generation by the subsequent 
phases. The intermediate text indicates 
what operations are to be carried out on 
what operands; the information table pro- 
vides the detailed information describing 
the operands that are to be processed. 


SOURCE STATEMENT PROCESSING 


statements, each 
of the source 


TO process’ source 
record (one card image) 
module is first read into an input buffer 
by a preparatory subroutine (GETCD). Ifa 
source module listing is requested, the 
record is recorded on an output data set 
(SYSPRINT). If both the EDIT option and 
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complete optimization are selected, the 
record and some control information used by 
phase 20 to produce a structured source 
listing are recorded on the SYSUT1 data 
set. Records are moved to an intermediate 
buffer until a complete source statement 
resides in that buffer. Unnecessary blanks 
are eliminated from the source statement, 
and the statement is assigned a classifica- 
tion code. A dispatcher subroutine 
(DSPTCH) determines from the code which 
subroutine is to continue processing the 
source statement. Control is then passed 
to that subroutine, which converts’ the 
source statement to its intermediate text 
representation and/or constructs informa- 
tion table entries describing its operands. 
After the entire source statement has been 
processed, the next is read and processed 
as described above. The recognition of the 
END statement causes phase 10 to complete 
its processing and return control to the 
FSD, which calls phase 15 for execution. 


The functions of phase 10 are performed 
by five groups of subroutines: 


Dispatcher subroutine 
Preparatory subroutine 
“Keyword subroutines 
Arithmetic subroutines 
Utility subroutines 


Dispatcher Subroutine 


The dispatcher subroutine (DSPTCH) con- 
trols phase 10 processing. Upon receiving 
control from the FSD, the DSPTCH subroutine 
initializes phase 10 processing and then 
calls the preparatory subroutine (GETCD) to 
read and prepare the first source state- 
ment. After the statement is prepared, 
control is returned to DSPTCH, which deter- 
mines if a statement number is associated 
with the source statement b@ing processed. 
If there is a Statement number, the DSPTCH 
subroutine constructs a statement number 
entry (refer to Appendix A, “Information 
Table") for the statement number. A text 
entry for the statement number is also 
created. The DSPTCH subroutine then deter- 
mines, from the code assigned to the source 
statement (refer to "Preparatory 
Subroutine"), which subroutine (either key- 
word or arithmetic) is to continue the 
processing of the statement, and passes 
control to that subroutine. When the 
source statement is completely processed, 
control is returned to the DSPTCH subrou- 
tine, which calls the preparatory subrou- 
tine to read and prepare the next source 
statement. 


Preparatory Subroutine 
The preparatory subroutine (GETCD) reads 


each source statement, records it on the 
SYSPRINT data set if the SOURCE option is 
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selected, and on the SYSUT1 data set if the 
EDIT option and complete optimization are 


selected, packs and classifies it, and 
assigns it an internal statement number 
(ISN)2. Packing eliminates unnecessary 


blanks, which may precede the first charac- 
ter, follow the last character, or be 
imbedded within the source statement. 
Classifying assigns a code to each type of 
source statement. The code indicates to 
the DSPTCH subroutine which subroutine is 
to continue processing the source state- 
ment. A description of the classifying 
process, along with figures illustrating 
the two tables (the keyword pointer table 
and the keyword table) used in this proc- 
ess, is given in Appendix A, 
"Classification Tables." The ISN assigned 
to the source statement is an internal 
sequence number used to identify the source 
statement. The source statement, after 
being prepared, resides in the storage area 
NCDIN in the format illustrated in Figure 


4. 

Cer a Te ee ee 1 
{Pointer to first character of (1 word) | 
|packed source statement beyond | 
| keyword? | 
{Internal statement number (1 word) | 
[Statement number indicator (#0 (1 word) | 
|if present; 0 if not present) | 
{Classification code (1 word) | 
{Statement number (5 words) | 
|Packed source statement (n words) | 
}------------------------ ee a ee ee SS 
{Group mark? (1 word) | 
J}*For arithmetic statements and statement| 


|functions, this field points to the first] 
[character of the packed statement. | 
|2End of statement marker. | 


Format of Prepared Source State- 
ment 


Figure 4. 


Keyword Subroutines | 


A keyword subroutine exists for each 
keyword source statement. A keyword source 
statement is any permissible FORTRAN source 
Statement other than an arithmetic state- 
ment or a statement function. The function 
of each keyword subroutine is to convert 
its associated keyword source statement (in 
NCDIN) into input usable by subsequent 


14Logical IF statements are 
internal statement numbers. 
given the first number and the 
Statement is given the next. 


assigned two 
The IF part is 
"trailing" 
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phases of the compiler. These subroutines 
make use of the utility subroutines and, at 


times, the arithmetic subroutines in per- 
forming their functions. To simplify the 
discussion of these subroutines, they are 


divided into two groups: 


1. Those that construct only information 
table entries. 


2. Those that construct information table 
entries and develop intermediate text 
representations. 


Note: One keyword subroutine, namely that 
which processes the IMPLICIT statement, is 
not assigned to either of the above stated 
groups. The processing performed by this 
subroutine (XIMPC) is somewhat specialized. 
The function of this subroutine is defined 
in Table 8. 


Table Entry Subroutines: Only four keyword 
subroutines belong to this group (refer to 


Table 8). Each is associated with a COM- 
MON, DIMENSION, EQUIVALENCE, or EXTERNAL 
keyword statement. 


The processing performed by these sub- 
routines is Similar. Each scans its asso- 
ciated statement (in NCDIN) ina left-to- 
right fashion and constructs appropriate 
information table entries for each of the 
operands of the statement. The types of 
information table entries that can be 
constructed by these subroutines are: 

e Dictionary entries for variables and 
external names. 
entries for 


e Common block name common 


block names. 


e Equivalence group 
lence groups. 


entries for equiva- 

e Equivalence variable entries for the 
variables in an equivalence group. 

e Dimension entries for arrays. 


The formats 
in Appendix A, 


of these entries are given 
"Information Table." 


Table entry and Text Subroutines: The 
keyword subroutines, other than those that 


are grouped as table entry subroutines, 
belong to this group (refer to Table 8). 
Each of these subroutines converts its 
associated statement by developing an 
intermediate text representation of the 
statement, which consists of text entries 
in operator-operand pair format, and con- 
structing information table entries for the 
operands of the statement. The processing 
performed by these subroutines is similar 
and is described in the following para- 
graphs. 


control from the DSPTCH 
subroutine, the keyword subroutine asso- 
ciated with the keyword statement being 
processed places a special operator into a 
text entry work area. This operator is 
referred to aS a primary adjective code and 


Upon receiving 


defines the type (e.g., DO,ASSIGN) of the 
statement. A left-to-right scan of the 
source statement is then initiated. The 


first operand is obtained, an information 
table entry is constructed for the operand 
and entered into the information table 
(only if that operand was not previously 
entered), and a pointer to the entry's 
location in that table is placed into the 
text entry work area. The mode (e.g., 
integer, real) and type (e.g., negative 
constant, array) of the operand are then 
placed into the work area. The text entry 
thus developed is placed into the next 
available location in the sub-block allo- 
cated for text entries of the type being 
created. 


Scanning is resumed and the next opera- 
tor is obtained and placed into the text 
entry work area. The next operand is then 
obtained, an information table entry is 
constructed for the operand and entered 
into the information table (again, only if 
that operand was not previously entered), 
and a pointer to the entry's location is 
placed into the text entry work area. The 
mode and type of the operand are placed 
into the work area. The text entry is then 
placed into the next available location in 
the sub-block allocated for text entries of 
the type being created. 


This process is terminated upon recogni- 
tion of the end of the statement, which is 
marked by a special text entry. The spe- 
cial text entry contains an end mark opera- 
tor and the ISN of the source statement as 
an operand. 


Note: Certain keywork subroutines in this 
group, namely those that process statements 
that can contain an arithmetic expression 
(e.g., IF and CALL statements) and those 
that process statements that contain I/O 
list items (e.g., READ/WRITE statements), 
pass control to the arithmetic subroutines 
to complete the processing of their asso- 
ciated keyword statements. 


Arithmetic Subroutines 


The arithmetic subroutines (refer to 
Table 8) receive control from the DSPTCH 
subroutine, or from various keyword subrou- 
tines, and make use of the utility subrou- 
tines in performing their functions, which 
are to: 
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e Process arithmetic statements. 

e Process statement functions. 

e Complete the processing of certain key- 
word statements (READ, WRITE, CALL, and 
IF.) 


describe the 
subroutines 


The following paragraphs 
processing of the arithmetic 
according to their functions. 
Arithmetic Statement Processing: In proc- 
essing an arithmetic statement, the arith- 
metic subroutines develop an intermediate 
text representation of the statement, and 
construct information table entries for its 
operands. These subroutines accomplish 
this by following a procedure similar to 
that described for keyword (table entry and 
text) subroutines. 


If one operator is adjacent to another, 
the first operator does not have an asso- 
ciated operand. In the example A=B(I)#¢C, 
the operator + has variable C as its 
associated operand, whereas the operator ) 
has no associated operand. If an operator 
has no associated operand, a zero (null) 
operand is assumed. 


Statement Function Processing: In convert- 
ing a statement function to usable input to 
supsequent phases of the compiler, the 
arithmetic subroutines develop an inter- 
mediate text representation of the state- 
ment function using sequence numbers as 
replacements for duinmy arguments. These 
subroutines also construct information 
table entries for those operands’ that 
appear to the right of the equal sign and 
that do not correspond to dummy arguments. 
The following paragraphs describe the proc- 
essing of a statement function py the 
arithmetic subroutines. 


When processing a statement function, 
the arithmetic subroutines: 


e Scan the portion of the statement func- 
tion to the left of the equal sign, 
obtain each dummy argument, assign each 
dummy argument a sequence numper (in 
ascending order), ana save the dummy 
arguments and their associated sequence 
numbers for subsequent use. 


e Scan the portion of the statement func- 
tion to the right of the equal sign and 
Obtain the first (or next) operand. 


e Determine if the operand corresponds to 
a dummy argument. If it does corre- 
spond, its associatead sequence number 
is placed into the text entry work 
area. If it does not correspond, a 
dictionary entry for the operand is 
constructed and entered into the infor- 
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Mation table, and a pointer to _ the 
entry's location is piaced into the 
text entry work area. (An opening 
parenthesis is used as the operator of 
the first text entry developed for each 


statement function and a closing paren- 


thesis is used as the operator of the 
last text entry developed for each 
statement function. ) 

e Place the text entry into the next 
available location in the _ sub-block 


allocated for SF skeleton text. 


e Resume scanning, obtain the next opera- 
tor, and place it into the text entry 
work area. 


e Obtain the operand to the right of this 
operator and process it as described 


above... 
Keyword Statement Completion: In addition 
to processing arithmetic statements and 


statement functions, the arithmetic subrou- 
tines also complete the processing of key- 
word statements that may contain arithmetic 
expressions or that contain I/O list items. 
The keyword subroutine associated with each 
such keyword statement performs the initial 
processing of the statement, but passes 
control to the arithmetic subroutines at 
the first possible occurrence of an arith- 
metic expression or an I/O list item. (For 
example, the keyword subroutine that proc- 
esses CALL statements passes control to the 
arithmetic subroutines after it has proc- 
essed the first opening parenthesis of the 
CALL, because the argument that follows 
this parenthesis may be in the form of an 
arithmetic expression.) The arithmetic 
subroutines complete the processing of 
these keyword statements in the normal 
Manner. That is, they develop text entries 
for the remaining operator-operand pairs 
and construct information table entries for 
the remaining operands. 


Utility Subroutines 


The utility subroutines (refer to Table 
8) aid the keyword, arithmetic, and DSPTCH 
subroutines in performing their functions. 
The utility subroutines are divided into 
the following groups: 


Entry placement subroutines. 
Text generation subroutines. 
Collection subroutines. 
Conversion subroutines. 


Entry Placement Subroutines: The utility 
subroutines. in this group place the various 
types of entries constructed by the key- 
word, arithmetic, and DSPTCH subroutines 
into the tables or text areas (i.e., 
sub-blocks) reserved for them. 
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Text Generation Subroutines: The utility 
subroutines in this group generate text 
entries (supplementary to those developed 
by the keyword and arithmetic subroutines) 
that: 


e Control the execution of implied DO's 
appearing in I/O statements. 


e Increment DO indexes and test them 

against their maximum values. 
e Signify the end of a source statement. 
Collection Subroutines: These utility sub- 
routines perform such functions as gather- 
ing the next group of characters (i.e., a 
string of characters bounded by delimiters) 
in the source statement being processed, 
and aligning variable names on aé_e word 
boundary for comparison to other variable 
names. 


Conversion Subroutines: These utility sub- 
routines convert integer, real, and complex 
constants to their binary equivalents and, 
if requested, verify that a converted con- 
stant is of integer mode. 


PHASE 15 


Before phase 15 gains control, phase 10 
has read the source statements, built the 
information table, and restructured the 
source statements into operator-operand 
pairs. When given control, phase 15 proc- 
esses common and equivalence entries in the 
common table, translates the text of arith- 
metic expressions, gathers information 
about branches and variables, converts 
phase 10 data text to a new text format, 
assigns relative addresses to constants and 
variables, and generates address constants 
when needed, to serve as address referen- 
ces. Thus, phase 15 modifies and adds to 
the information table and translates phase 
10 normal and data text to their phase 15 
formats. 


Phase 15 is divided into three overlay 
segments, STALL, PHAZ15, and CORAL. Chart 
04 shows the overall logic of the phase. 


STALL processes both common and equiva- 
lence entries in the information table. It 
finds the maximum size of each common 
block, assigns locations to variables in 
each common block, and plans the storing of 
operands equated by EQUIVALENCE statements. 


It also determines the head of arrays 
referred to in EQUIVALENCE statements. 
(The head is the lowest-valued starting 


address of two or more arrays after their 
repositioning has been planned by equiva- 
lence processing.) CORAL later uses the 
head during the computation of relative 
addresses for variables and arrays. 


PHAZ15 translates and reorders the text 
entries for arithmetic expressions from the 
Operator-operand format of phase 10 to a 
four-part form suitable for phase 20 proc- 
essing. The new order permits phase 25 to 
generate machine instructions in the cor- 
rect sequence. PHAZ15 blocks the text and 
collects information describing the blocks. 
The information, needed during phase 20 
optimization, includes tables on branching 
locations, and on constant and variable 
usage. 


CORAL, the last overlay segment of phase 
15, performs five functions. It first 
converts phase 10 data text to a form more 
eaSily evaluated by phase 25. CORAL then 
assigns relative addresses to all varia- 
bles, constants, and arrays. During one 
phase of relative address assignment, CORAL 
rechains phase 15 data text in order to 
simplify the generation of text card images 
by phase 25. CORAL also assigns address 
constants, when needed, to serve as address 
references for all operands. Lastly, asa 
user option, CORAL prints a storage map of 
named items (variables, arrays, and exter- 
nal references) as recorded in the informa- 
tion table. 


STALL PROCESSING 


STALL first rechains entries for varia- 
bles in the dictionary by sorting alphabet- 
ically the entries within each chain. The 
rechaining frees storage in each entry for 
later use by CORAL. 


As a second function, STALL checks the 
statement-number section of the information 
table, noting undefined statement numbers. 


STALL then processes common entries in 
the information table. It computes the 
offset (displacement) of each variable ina 
common block from the start of the common 
block. The offsets are subsequently used 
to assign relative addresses to common 
variables. The offsets are recorded in the 
dictionary entries for the variables. The 
total size of each common block is aiso 
calculated. The block size is used by 
phase 25 to generate a control section for 
the common block. 

Lastly, STALL processes equivalence 
entries in the information table. The 
processing plans’ the placing of the oper- 
ands of each equivalence group at the same 
location in storage. During the processing 
STALL recognizes a variable that must be 
made equivalent to previously processed 
variables in common. 


Chart 05 shows the overall processing of 
STALL. 
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Rechaining Entries for Variables 


The STALL subroutine DCTSRT begins by 
rechaining entries for variables in the 
information table. Each dictionary entry 
created by phase 10 contains two chain 
address fields (refer to Appendix A, 
"Information Table Components"). DCTSRT 
frees one of the chain address fields for 
later use by CORAL. It does this by 
sorting alphabetically within each length 
grouping and then rechaining the entries. 
After the entries have been rechained, the 
dictionary consists of one chain for each 


variable-name length. The chains of 
entries describing symbols of 3 or less 
characters are arranged in descending 


alphabetic order, while the chains of 
entries describing symbols of 4 or more 
characters are arranged in ascending alpha- 


betic order. As an integral part of 
rechaining, DCTSRT also constructs dic- 
tionary entries for the imaginary parts of 


complex variables and constants. 


Checking for Undefined Statement Numbers 


After subroutine DCTSRT has rechained 
the dictionary, subroutine LABSCN checks 
for undefined statement numbers. This 
action is taken to insure that every state- 
ment number that is referred to is also 
defined. LABSCN scans the chain of state- 
ment number entries in the information 
table (refer to Appendix A, “Statement 
Number/ Array Table") and examines a bit in 
the byte A usage field of each such entry. 
This bit is set by phase 10 to indicate 
whether or not it encountered a definition 
of that statement number. If the bit 
indicates that the statement number is not 
defined, LABSCN places an entry in the 
error table for later processing by phase 
30: 


Processing of Common Entries in the 
Information Table 


After the statement numbers have been 
checked, subroutine COMN processes common 
entries in the information table. It com- 


putes the offsets (displacements) of varia- 
bles and arrays from the start of the 
common block containing them and calculates 


the total size in bytes of each common 
block. COMN records the offsets in the 
dictionary entries for the variables and 


the block size in the common table entry 
for the name of the common bliock (refer to 
Appendix A, “Common Table"). It also plac- 
eS a pointer to the common table entry for 
the block name in the dictionary entry for 
each variable or array in that common 
block. 
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Processing of Equivalence Entries in the 


Information Table 


Subroutine EQU next gathers additional 
information about equivalence groups and 
the variables in them. It computes a group 
head* and the offset (displacement) of each 
variable in the group from this head. It 
records this information in the common 
table entries for the group and for the 
variables, respectively (refer to Appendix 
A, “Common Table"). EQU identifies and 
flags in their dictionary entries variables 
and arrays put into common via the EQUIVA- 
LENCE statement. It also error-checks’ the 
variables and arrays to verify that the 
associated common block has not been im- 
properly extended because of the equiva- 
lence declaration. If a common block is 
legitimately enlarged by an equivalence 
operation, subroutine EQU  recomputes’ the 
Size of the common block and enters the 
size into the common table entry for the 
name of the common block. 


If the name of a variable or array 
appears in more than one equivalence group, 
EQU recognizes the combination of groups 
and modifies the dictionary entries for the 
variables to indicate the equivalence oper- 
ations. EQU checks arrays appearing in 
more than one equivalence group to verify 
that conflicting relationships have not 
been established for the array elements. 


During the processing of both common and 
equivalence information, subroutine TESTBN 
is given control to check that variables 
and arrays fall on boundaries appropriate 
to their defined types. If a variable or 
array is improperly aligned, TESTBN places 
an entry in the error table for processing 
by phase 30. 


PHAZ15 PROCESSING 


The functions of PHAZ15 are text block- 
ing, arithmetic translation, information 
gathering, and reordering of the statement 
number chain. Information gathering occurs 
only if optimization (either intermediate 
or complete) has been selected; it takes 
place concurrently with text blocking and 
arithmetic translation during the same scan 
of intermediate text. Reordering of the 
statement number chain occurs after PHAZ15 
has completed the blocking, arithmetic 
translation, and information gathering. 


PHAZ15 divides intermediate text into 
blocks for convenience in obtaining infor- 


1The head of a equivalence group is that 
variable in the group from which all other 
variables or arrays in the group can be 
addresses by a positive displacement. 
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Mation from the text. 


Each block begins 
with a statement number definition and ends 
with the text entry just preceding the next 
statement number definition. PHAZ15 
records information describing a text block 
in a statement number text entry and in an 
information table statement number entry. 


During the same scan of text in which 
blocking occurs, PHAZ15 translates arith- 
metic expressions. The conversion is from 
the operation-operand pairs of phase 10 to 
a four part format (phase 15.text). The 
new format follows the sequence in which 
algebraic operations are performed. in 
general, phase 15 text is in the same order 
in which phase 25 will generate machine 
instructions. 2 PHAZ15 copies, unchanged 
into the text area, phase 10 text that does 
not require arithmetic translation or other 
special handling. 


During the building of phase 15 text for 
a given block (if complete optimization has 
been selected), PHAZ15 constructs tables of 
information on the use of constants and 
variables in that text block. It stores 
information on variables and constants that 
are used within a block, and variables that 
are defined within a block. PHAZ15 also 
gathers information on variables not first 
used and then defined. The foregoing usage 
information is recorded in the statement 
number text for each block for later use by 
phase 20. 


Concurrently with text blocking, arith- 
metic translation, and gathering of 
constant/variable usage information, PHAZ15 
discovers branching text entries and 
records the branching or connection infor- 
mation. This information, consisting ini- 
tially of a table of branches from each 
text block (forward connections), is stored 
in a special array. Branching (connection) 
information is used during phase 20 optimi- 
zation. 


After PHAZ15 has completed the previous- 
ly mentioned processing, it reorders the 
statement number chain of the information 
table. The original order of statement 
numbers, as phase 10 recorded them, was in 
order of their occurrence in source state- 
ments as either definitions? or operands. 
The new sequence after phase 15 reordering 
is according to source statement occurrence 
as definitions only. The new order is 
established to facilitate phase 20 process- 
ing. 


2If optimization is selected, phase 20 may 
further manipulate the phase 15 text. 

3A statement number occurs as a_ definition 
when that statement number appears to the 
left of a source statement. 


Lastly, PHAZ15 acquires a table of back- 
ward connection information consisting of 
branches into each statement number, or 
text block. - PHAZ15 derives this informa- 
tion from the forward connection informa- 
tion it previously obtained. Thus, connec- 
tion information is of two types, forward 
and backward. PHAZ15 records a table of 
branches from. each text block and a table 
of branches into each text block. Connec- 
tion information of both types is used 
during phase 20 optimization. 


Charts 06, 07, and 08 depict the flow of 
control during PHAZ15 execution. 


Text Blocking 


During its scan and conversion of phase 
10 text, PHAZ15 sections the module into 
text blocks, which are the basic unit upon 
which the optimization and register assign- 
ment processes of phase 20 operate. A text 
block is a series of text entries that 
begin with the text entry for a statement 
number and end with the text entry that 
immediately precedes the text entry for the 
next Statement number. (The statement num- 
ber may be either programmer defined or 
compiler generated.) When PHAZ15 encoun- 
‘ters a statement number definition (i.e., 
the phase 10 text entry for a statement 
number) it begins a text block. It does 
this by constructing a statement number 
text entry (refer to Appendix B, “Phase 15 
Intermediate Text Modifications"). PHAZ15 
also places a pointer to the statement 
number text entry into the statement number 
entry (information table) for the associat- 
ed statement number. 


PHAZ15 resumes its scan and converts the 
phase 10 text entries following the state- 
ment number definition to their phase 15 
formats. After each phase 15 text entry is 
formed and chained into text, PHAZ15 places 
a pointer to that text entry into the 
BLKEND field of the previously constructed 
statement number text entry. This field is 
thereby continually updated to point to the 
last phase 15 text entry. 


When the next statement number defini- 
tion is encountered, PHAZ15 begins the next 
text block in the previously described 
manner. A pointer to the text entry that 
ends the preceding block has already been 
recorded in the BLKEND field of the state- 


ment number text entry that begins that 
block. Thus, the boundaries of a text 
block are recorded in two places: ‘the 


beginning of the block is recorded in the 
associated statement number entry 
(information table); the end of the _ block 
is recorded in the BLKEND field of the 
associated statement number text entry. 
All text blocks in the module are identi- 
fied in this manner. 
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Note: For each ENTRY statement in the 
source module, phase 10 generates a state- 
ment number text entry and places it into 
text preceding the text for the ENTRY 
statement. Phase 10 also ensures that the 
Statement following an ENTRY statement has 
a Statement number; if a statement number 
is not provided by the programmer, phase 10 
generates one. The text entries for each 
ENTRY statement therefore form a separate 
text block, which is referred to as an 
entry block. 


Figure 5 illustrates the concept of text 
blocking. In the figure, two text blocks 
are shown: one beginning with statement 
number 10; the other with statement number 
20. The statement number entry for state- 
ment number 10 contains a pointer to the 
Statement number text entry for statement 
number 10, which contains a pointer to the 
text entry that immediately precedes the 
statement number text entry for statement 
number 20. Similar pointers exist for the 
text block starting with statement number 
20. 


Arithmetic Translation 


Arithmetic translation is the reordering 
of arithmetic expressions in phase 10 text 
format to agree with the order in which 
algebraic operations are performed. Arith- 
Metic expressions may exist in IF, CALL, 
ASSIGN, and GOTO statements and I/O data- 
list, as well as in arithmetic statements 
and statement functions. 


When PHAZ15 detects a primary adjective 
code for a statement that needs arithmetic 
translation, it passes control to the 
arithmetic translator (ALTRAN). If the 
phase 10 text for the statement does not 
require any type of special handling, 
ALTRAN reorders it into a series of phase 
15 text entries that reflect the sequence 
in which arithmetic operations are to be 
carried out. During the reordering proc- 
ess, ALTRAN calls various supporting rou- 
tines that perform checking and resolution 
(e.g., the resolution of operations involv- 
ing operands of different modes) functions. 


Throughout the reordering process, 
ALTRAN is checking for text that requires 
special handling before it can be placed 
into the phase 15 text area. (Special 
handling is required for complex expres- 
sions, terms involving unary minuses (e.g., 
A=-B), subscript expressions, statement 
function references, etc.) If special text 
processing is required, ALTRAN calis one or 
more subroutines to perform the required 
processing. 


During reordering and, if required, spe- 
cial handling, subroutine GENER is called 
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Statement Number Entry for 
Statement Number 10 







Statement Number Entry for 
Statement Number 20 


* LDF is the mnemonic for the statement number operator 


Figure 5. Text Blocking 


to format the phase 15 text entries and to 
place them into the text area. 


REORDERING ARITHMETIC EXPRESSIONS: The 
reordering of arithmetic expressions is 
done by means of a pushdown table. This 
table is a last-in, first-out list. After 
the table is initialized (i.e., the first 
operator-operand pair of an arithmetic 
expression is placed into the table), the 
arithmetic translator (ALTRAN) compares the 
operator of the next operator-operand pair 
(term) in text with the operator of the 
pair at the top of the pushdown tabie. As 
a result of each comparison, either a term 
is transferred from phase 10 text to the 
table, or an operator and two operands 
(triplet) are brought from the table to the 
phase 15 text area, eliminating the top 
term in the pushdown table. 


The comparison made to determine whether 
a term is to be placed into the pushdown or 
whether a triplet is to be taken from the 
pushdown is always between the operator of 
a term in phase 10 text and the operator of 
the top term in the table. Each comparison 
is made on the basis of relative forcing 
strength. A forcing strength is a value 
assigned to an operator that determines 
when that operator and its associatea oper- 
ands are to be placed in phase 15 text. 
The relative values of forcing strengths 
reflect the hierarchy of algebraic opera- 
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PHASE 15 TEXT 


tions. 
ious operators appear in Table 1. 


The forcing strengths for the var- 


Table 1. Operators and Forcing Strengths 
ssh sar cm a a ec To eon et oe 1 
| { Forcing | 
| Operator | Strength | 
}---------------------------- }------------ { 
jEnd Mark | 1 | 
{= l 2 | 
|) | 3 | 
|, i 6 | 
| -OR. | 7 | 
}-AND. | 8 | 
| -NOT. | 9 | 
{-EHQ., .NE., | 10 | 
[<GT..,, .Lf. 4 | | 
|.GE., LE. | | 
|+, —, minus ( | 11 | 
lat ae | 12 
| ** | 13 | 
| (£ --left parenthesis after | 14 | 
| a function name | | 
| | 
| (s --left parenthesis after | 15 | 
| an array name | | 
| ¢ | 16 | 
a oI eee ee en Ce 4 
When the arithmetic translator (ALTRAN) 


encounters the first operator-operand pair 
(phase 10 text entry) of a statement, the 
pushdown table is empty. Since the trans- 
lator cannot yet make a comparison between 
text entry and table element, it enters the 


first text entry in the top position of the 
table. The translator then compares the 
forcing strength of the operator of the 
next text entry with that of the table 
element. If the strength of the text 
operator is greater than that of the top 
(and only) table element, the text entry 
(operator-operand pair) becomes the top 
element of the table. The original top 
element is effectively “pushed down" to the 
next lower position. In Figure 6, the 
number-1 section of the drawing shows the 
pushdown table at this time. 


The operator of the next text entry 
(operator C--operand C at section 2) is 
compared with the top table element 
(operator B--operand B at section 1) in a 
Similar manner. 


When a comparison of forcing strengths 
indicates that the strength of the text 
Operator (operator C, section 2), is less 


than or equal to that of the top table 
element (operator B), the table element is 
said to be "forced." The forced operator 
(operator B) is placed in the new phase-15 
text entry (section 3 of the figure) with 
its operand (operand B) and the operand of 
the next lower table entry (operand A). 
Note that ALTRAN has generated a new oper- 
and t (see section 3) calied a “temporary." 
A temporary is a compiler-generated operand 
in which a preliminary result may be held 
during object-module execution.+ With oper- 
ator B, operand B, and operand A (a 
triplet) removed from the pushdown table, 
the previously entered operator-cperand 
pair (operator A, section 1) now becomes 
the top element of the table (section 4). 


1A given temporary may be eliminated by 
phase 20 during optimization. 


1. Text in Pushdown Table 2. 


Op B 


Oprnd B 
Op A Oprnd A 






Top Element 





4. New Top Element of Pushdown 


NOTE: A phase 15 text entry having an arithmetic operator may be envisioned as 


Op A 


Operator 


. Operation 


ALTRAN assigns .the previously generated 
temporary t as the operand of this pair. 
This temporary represents’ the previous 
(operator B--operand A--operand 
Bis 


Comparisons and text-to-table exchanges 
continue, a higher strength text operator 
"pushing" a phase 10 text entry into the 
tabie and a lower strength text operator 
"forcing" the top table operator and its 
operands (triplet) from the table. In each 
case, the forced table items pecome the new 
phase 15 text entry. An exception to the 
general rule is a left parenthesis, which 
has the highest forcing strength. Opera- 
tors following the left parenthesis can be 
forced from the table only by a right 
parenthesis, although the intervening oper- 


ators (between the parentheses) are of 
lower forcing vaiue. When the translator 
reaches an end mark in text, its forcing 


strength of 1 forces all remaining elements 
from the table. 


SPECIAL PROCESSING OF ARITHMETIC EXPRES- 
SIONS: As Stated before, arithmetic trans- 
lation involves reordering a group of phase 
10 text entries to produce a new group of 
phase 15 text entries representing the same 
source statement. Certain types of 
entries, however, need special handling 
(for example, subscripts and functions). 
When it has been determined that special 
handling is needed, control is passed to 
one or more other subroutines (refer to 
Chart 07) that perform the desired process- 
ing. 


The following expressions and terms need 
special handling before they are placed in 
phase 15 text: complex expressions, terms 
involving a unary minus, terms involving 
powers, commutative expressions, subscript 


Phase 10 Text Entries 


Op Cc Oprnd C 
Op D Oprnd D 


3. New Phase 15 Text Entry 


Current phase 10 text entry 


Next phase 10 text entry 


Operand 1 Operand 2 Operand 3 


Operand | = operand 2 - operator - operand 3, where the equal sign is implied. 


Figure 6. 
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Text Reordering Via the Pushdown Table 
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expressions, routine or subprogram referen- 


ces, Statement function references, and 
expressions involved in logical IF state- 
ments. 


Complex Expressions: A complex expression 
is converted into two expressions, a real 


expression and an imaginary one. For real 
elements in the expression, complex tempo- 
raries are generated with zero in the 
imaginary part and the real element in the 


real part. For example, the complex 
expression B + C + 25. is treated as: 

De er Ne ge ee 1 
| B + c + 25. | 
| real real real | 
}-------------------~--------------------- { 
| B + c + 0. | 
| imag imag imag | 
Seeger eee ea g eager RE Re er Ra ee SE El eee J 


An expression is not treated as complex 
if the “result" operand (left of the equal 
Sign in the source statement) is real. In 


this case, the translator places only the 
real part of the expression in phase 15 
text. But if a complex multiplication, 


division, or exponentiation is involved in 
the expression, the real and imaginary 
parts will appear in phase 15 text, but 
only the real part of the result will be 
used at execution time. 


Terms Containing a Unary Minus: In terms 
that contain unary minuses, the unary min- 


uses are combined with additive operators 
(+,-) to reduce the number of operators. 
This combining, done by subroutines UNARY 
and SWITCH, may result in reversed opera- 
tors or operands or both in phase 15 text. 
For example, -(B-C) becomes C-B, and At(-B) 
becomes A-B. This process reduces’ the 
number of machine instructions that phase 
25 must generate. 


Operations Involving Powers: Several kinds 
of special handling are provided by subrou- 


tines UNARY and EXPON for operations 
involving powers. Multiplications by pow- 
ers of two are converted to left shift 
operations. A constant integer power of 


two raised to a constant integer power is 


converted to the equivalent left shift 
operation. Lastly, a constant or variable 
raised to a constant integer power between 
-6 and +6 is converted to a series of 
multiplications (and a division into one, 
if necessary). This handling requires less 
execution time than using an exponentiation 
subroutine. 


Commutative Operations: If an operation is 
commutative (either operand can be operated 


upon, such as in addition or 
multiplication), the two operands are reor- 
dered to agree with their absolute loca- 
tions in the dictionary. 
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Subscripts: Subroutines SBGLUT, SUBADD, 
SUBMLT, and SUBSCR perform subscript proc- 
essing. Subscripted items are processed 
one at a time throughout the subscript. If 
the subscripted item itself is an expres- 
sion, it is first processed via the trans- 


lator. Text entries are then generated to 
multiply the subscript variable by the 
dimension factor and length. Each sub- 


script item is handled in a similar manner. 
When all subscript items have been proc- 
essed, phase 15 text entries are generated 
to add all subscript values together to 
produce a single subscript value. 


In general, during compilation, con- 
Stants in subscript expressions are con- 
bined, and their composite value is placed 
in the displacement field of the phase 15 
text entry for the subscript item. (Refer 
to Appendix B, "Phase 15/Phase 20 Inter- 
mediate Text Modifications.") Phase 25 uses 
the value in the displacement field to 
generate, in the resultant object instruc- 
tions, the displacement for referring to 
the elements in the array. This combining 
of constants reduces the number of instruc~ 
tions needed during execution to compute 
the subscript value. 


Expressions Referring to In-Line Routines 
or Subprograms: Expressions containing 


references to in-line routines or subpro- 
grams are processed by the following sub- 
routines: FUNDRY, NEGCHK, XPARAM, BLTNFN, 
and DFUNCT. . 


Arguments that are expressions are 
reduced by the translator to a single 
temporary, which is used as the argument. 


If an argument is a subscripted variable, 
subscript processing (previously discussed) 
reduces the subscript to a Single sub- 
scripted item. Either subroutine DFUNCT 
(for references to library routines) or 
subroutine BLINFN (for references to in- 
line routines) then conducts a series of 
tests on the argument and perform the 
processing determined by the results of the 
tests. 


If a function is not external and is in 
the IFUNTB table (refer to Appendix A, 
"Subprogram Table"), the IFUNTB table is 
scanned to determine if the requirea 
routine is in-line. Then, the mode is 
tested. If the routine is in-line and the 
mode is as expected, BLTNFN either gener- 
ates text or substitutes a special operator 
(such as those for ABS or FLOAT) in the 
phase 15 text so that phase 25 can later 
expand the function. PHAZ15 provides in- 
line routines itself.1 Instead of placing a 


1BLTNFN expands the following functions: 
TBIT, LAND, LOR, LXOR, ADDR, SNGL, REAL, 
AIMAG, DCMPLX, CMPLX, DCONJG, and CONJG. 


special operator in text, PHAZ15 inserts a 
regular operator, such as the operator for 
AND or STORE. 


If the mode and/or number of arguments 
in the function is not as expected, another 
test is performed. The test determines if 
a previous reference was made correctly for 
these arguments. If the previous reference 
waS aS expected, an error is assumed to 
exist. Otherwise, the function is assumed 
to be external. 


If a function is external (either used 
in an EXTERNAL statement or does not appear 
in the IFUNTB table), text is generated to 
load the addresses of any arguments that 
are subscripted variables into a parameter 
list in the adcon table. (If none of the 
arguments are subscripted variables, the 
load address items are not required.) A 
text entry for a subprogram or function 
call is then generated. The operator of 
the text entry is for an external function 
or subprogram reference. This entry points 
to the dictionary entry for the name. The 
text representation of the argument list is 
then generated and placed into the phase 15 
text chain. 


If a function is not external, is in the 
IFUNTB table, but does not represent an 
in-line routine, text is generated to load 
the addresses of any arguments that are 
subscripted variables into a parameter list 
in the adcon table. (If none of the 
arguments are subscripted variables, the 
load address items are not required.) A 
text entry having a library function 
Operator is generated. This entry points 
to the IFUNTB entry for the function. The 
text representation of the argument list is 
then generated and placed into the phase 15 
text chain. 


Expressions Containing Statement Function 
References: For expressions containing 


statement function references, the argu- 
ments of the statement function text are 
reduced to single operands (if necessary). 
These arguments and their mode are stored 
in an argument save table (NARGSV), which 
serves as a dictionary for the statement 
function skeleton pointed to by the dic- 
tionary entry for the statement function 
name. The argument save table is used in 
conjunction with the usual pushdown proce- 
dure to generate phase 15 text items for 
the statement function reference. When the 
translator encounters an operand that is a 
dummy argument, the actual argument corre- 
sponding to the dummy is picked up from the 
argument save table and replaces the dumny 
argument. 


Logical Expressions: Subroutines ALTRAN, 
ANDOR, RELOPS, and NOT perform a special 
process, called anchor point, on logical 
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expressions containing relational opera- 
tors, ANDS, ORS, and NOTs, so that, at 
object time, unnecessary logical tests are 
eliminated. With anchor-point “optimiza- 
tion," only the minimum number of object- 
time logical tests are made before a branch 
or fall-through occurs. For example, with 
anchor-point handling, the statement 
IF(A.AND.B.AND.C) GO TO 500 will produce 
(at object time) a branch to the next 
statement if A is false, because B and C 
need not be tested. Thus, only a minimum 
number of operands will be tested. Without 
anchor-point handling of the expression 
during compilation, all operands would be 
tested at object time. Similar special 
handling occurs for text containing logical 
ORS. 


When a primary adjective code fora 
logical IF statement or an end-of-DO IF is 
placed in the pushdown table, a scan of 
phase 10 text determines if the associated 
statement can receive anchor-point hand- 
ling. The statement can receive anchor- 
point handling if two conditions are met. 
There must not be a mixture of ANDs and ORs 
in the statement. A logical expression, if 
it is in parentheses, must not be negated 
by the NOT operator. If these two 
conditions are not met, special handling of 
the logical expression does not occur. 


Gathering Constant/Variable Usage 
Information 


During the conversion of the phase 10 
text entries that follow the beginning of a 
text block (i.e., the text entries. that 
follow a statement number definition) to 
phase 15 format, the PHAZ15 subroutine MATE 
gathers usage -information for the variables 
and constants in that block. This informa- 
tion is required during the processing of 
the complete-optimized path through phase 
20 (refer to "Phase 20"). If complete- 
optimized processing is not selected, this 
information is not compiled. Subroutine 
MATE records the usage information in three 
fields (MVS, MVF, and MVX), each 128 bits 
long, of the statement number text entry 
for the block (refer to Appendix B,. “Phase 
15 Intermediate Text Modifications"). The 
MVS field indicates which variables are 
defined (i.e., appear in the operand 1 
position of a text entry) within the text 


of the block. The MVF field indicates 
which variables, constants, and base 
variables (refer to CORAL PROCESSING, 


"“Adcon and Base Variable Assignment") are 
used (i.e., appear in either the operand 2 
or operand 3 position of a text entry) 
within the text of the block. The MVX 
field indicates which variables are defined 
but not first used (not busy-on-entry) 
within the text of the block. 
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Subroutine MATE records the usage infor- 
mation for a variable or constant at a 
specific bit location within the three 
fields. (Base variables are processed dur- 
ing CORAL PROCESSING.) The bit location at 
which the usage information is recorded is 
determined from the coordinate assigned to 
the variable or constant when it is first 
encountered in text. 


Coordinates are assigned to variables 
and constants in the following manner: 


e The first 59 unique variables and/or 
constants appearing in the text created 
by phase 15 are assigned coordinates 2 
through 60, respectively.1 The coordi- 
nates are assigned in order of increas- 
ing coordinate number. (A coordinate 
between 2 and 60 may be assigned to a 
base variable if fewer than 59 unique 


variables and constants appear in the 
text.) 

e The next 20 unique variables are 
assigned coordinates 61 through 80, 
respectively. The coordinates are 


assigned in order of increasing coordi- 
nate number. (If constants are encoun- 
tered after coordinate 60 has been 
assigned, they are not assigned coordi- 
nates.) 


e The coordinates 81 through 128 are 
reserved for assignment to base varia- 
bles (refer to CORAL PROCESSING, "“Adcon 
and Base Variable Assignment"). 


Subroutine MATE assigns the first varia- 
ble or constant in phase 15 text a  coordi- 
nate number of 2, which indicates that the 
usage information for that variable or 
constant, regardless of the block in which 
it appears, is to be recorded in bit 
position 2 of the MVS, MVF, and MVX fields. 
MATE assigns the second variable or con- 
Stant a coordinate number of 3 and records 
its usage information in bit position 3 of 


the three fields. MATE continues this 
process until coordinate 60 has been 
assigned to a variable or constant. After 
‘coordinate number 60 has been assigned, 


MATE only 
20 unique variables. 


assigns coordinates to the next 
(MATE does not assign 
coordinates to or gather usage information 
for unique constants encountered after 
coordinate number 60 has been assigned.) 
It assigns these variables coordinates 61 
through 80, respectively. It records the 


4The coordinate 1 is assigned to items such 


as unit numbers (i.e., data set reference 
numbers), complex variables in common, 
arrays that are equivalenced, variables 


that are equivalenced to arrays, and varia- 
bles that are equivalenced to variables of 
different modes. 
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usage information for each variable at the 
assigned bit location in the three fields. 
MATE does not assign coordinates to or 
gather usage information for unique varia- 
bles encountered after coordinate number 80 
has been assigned. 


Subroutine MATE uses a combination of 
the MCOORD vector, the MVD table, and the 
byte-c usage fields of the dictionary 
entries (refer to Appendix A, “Dictionary") 
to assign, keep track of, and record coor- 
dinate numbers. MCOORD contains the number 
of the last coordinate assigned. The MVD 
table is composed of 128 entries, with each 
entry containing a pointer to the dictiona- 
ry entry for the variable or constant to 
which the corresponding coordinate number 
is assigned or to the information table 
entry for the base variable to which the 
corresponding coordinate is assigned. The 
coordinate number assigned to a variable or 
constant is recorded in the byte-C usage 
field of the dictionary entry for that 
variable or constant. 


Subroutine MATE does not assign coordi- 
nates to or record usage information for 
unique constants encountered in text after 
coordinate number 60 has been assigned and 
unique variables encountered in text after 
coordinate number 80 has been assigned. If 
MATE encounters a new constant after coor- 
dinate 60 has been assigned or a new 
variable after coordinate 80 has been 
assigned, it records a zero in the byte-c 


usage fiela of its associated dictionary 
entry. Phase 20 optimization deals only 
with those constants and variables that 
have been assigned coordinate numbers 


greater than or equal to 2 and less than or 
equal to 80. 


After a phase 15 text entry has been 
formed, subroutine MATE is given control to 
determine and record the usage information 
for the text entry. It examines the text 
entry operands in the order: operand 2, 
operand 3, operand 1. If operand 2 has not 
been assigned a coordinate (indicating that 
this is the first occurrence of the operand 
in the module), subroutine MATE assigns it 
the next coordinate, enters the coordinate 
number into the byte-C usage field of the 
dictionary entry for the operand, and plac- 
es a pointer to that dictionary entry into 
the MVD table entry associated with the 
assigned coordinate number. After MATE has 
assigned the coordinate, or if the operand 
was previously assigned a coordinate, it 
records the usage information for the oper- 


and. The operand's associated coordinate 
bit in the MVF field (of the statement 
number text entry for the block containing 


the text entry under consideration) is set 
on, indicating that the operand is used in 
the block. MATE executes a similar proce- 


dure of the text 


entry. 


to process operand 3 


If operand 1 of the text entry has not 
been assigned a coordinate, MATE assigns it 
the next and records the following usage 
information for operand 1: 


e Its associated coordinate bit in the 
MVX field is set on only if the asso- 
ciated coordinate bit in the MVF field 
is not on. (If the associated MVF bit 
is on, operand 1 of the text entry was 
previously encountered in the block as 
a use and therefore is not not busy-on- 
entry.) 


e Its associated coordinate bit in the 
MVS field is set on, indicating that it 
is defined within the block. 


This process is repeated for all the 
phase 15 text entries that are formed 
following the construction of a statement 
number text entry and preceding the 
construction of the next statement number 
text entry. When the next statement number 
text entry is constructed, all the usage 
information for the preceding block has 
been recorded in the statement number text 
entry that begins that block. The same 
procedure is followed to gather the usage 
information for the next text block. 


Gathering Forward Connection Information 


An integral part of the processing of 


PHAZ15 is the gathering of forward connec- 
tion information, which indicates which 
text blocks pass control to which other 


text blocks. Forward connection informa- 
tion is used during phase 20 optimization. 


Forward connection information is 
recorded in a table called RMAJOR. Each 
RMAJOR entry is a pointer to the statement 
number entry associated with a statement 
number that is the object of a branch or a 
fall-through. Because each statement num- 
ber entry contains a pointer to the text 
block beginning with its associated state- 
ment number (refer to “Text Blocking"), 
each RMAJOR entry points indirectly toa 
text block. 


For each new text block, PHAZ15 places a 
pointer to the next available entry in 
RMAJOR into the forward connection field of 
the associated statement number entry 
(refer to Appendix A, "Statement 
Number/Array Table"). The statement number 
entry associated with the text block there- 
fore points to the first entry in RMAJOR in 
which the forward connection information 
for that block is to be recorded. 


After starting a text block, PHAZ15 
converts the phase 10 text following the 
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Statement number definition to phase 15 
text. As each phase 15 text entry is 
formed, it is analyzed to determine if it 
is a GO TO or compiler generated branch. 
If it is, a pointer to the statement number 
entry for each statement number that may be 
branched to as a result of the execution of 
the GO TO or generated branch is recorded 
in the next available entry in RMAJOR. (If 
two Or more branches to the same statement 
number appear in the text following a 
statement number definition and before the 
next, only one entry is made in RMAJOR for 
the statement number to be branched to.) 


When PHAZ15 encounters the next state- 
ment number definition, it starts a new 
block. If the new block is an entry block, 
PHAZ15 saves a pointer to its associated 
statement number entry for subsequent use 
and processes the text for the block. 


If the new block is 
block nor an 


neither an entry 
entry point (i.e., a block 


immediately following an entry block), 
PHAZ15 records the fall-through connection 
information (if any) for the previous 


block. If the previous block is terminated 
by an unconditional branch, it does not 
fall-through to the new block. If the 
previous block can fall-through to the new 
block, PHAZ15 records a pointer to the 
Statement number entry for the new block in 
the next location of RMAJOR. It then flags 
this as the last forward connection for the 
previous block. 


If the new block is an entry point 
(i.e., a block immediately following an 
entry block), PHAZ15 records the fali- 
through connection (if any) for the 


previous non-entry block. It does this in 
the manner described in the previous para- 
graph. It then records the forward connec- 
tion information for all intervening entry 


blocks (i.e., entry blocks between the 
previous non-entry block and the new 
block). (PHAZ15 has saved pointers to the 


statement number entries for all interven- 
ing entry blocks.) Each such entry block 
passes control directly to the new block 


and therefore has only one forward connec- 
tion. To record the forward connection 
information for the intervening entry 


blocks, PHAZ15 places a pointer to the next 
available entry in RMAJOR into the forward 
connection field of the statement number 


entry for the first intervening entry 
block. In this RMAJOR entry, PHAZ15 
records a pointer to the statement number 


entry for the new block. 
entry as the last, and only, 


It flags this 
RMAJOR entry 


for the entry block. PHAZ15 repeats this 
procedure for the remaining intervening 
entry blocks (if any). PHAZ15 then pro- 


ceeds to process the new text block. 
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When all the connection information for 
a block has been gathered, each RMAJOR 
entry for the block, the first of which is 
pointed to by the statement number entry 
for the block and the last of which is 
flagged as such, points indirectly toa 
block to which that block may pass control. 


Figure 7 illustrates the end result of 
gathering forward connection information 
for sample text blocks. Only the forward 
connection information for the blocks 
beginning with statement numbers 10 and 20 
is shown. Inthe figure, it is assumed 
that: 


e The block started by statement number 
10 may branch to the blocks started by 
statement numbers 30 and 40 and will 
fall-through to the block started by 
statement number 20 if neither of the 
branches is executed. 


e The block started by statement number 
20 may branch to the blocks started by 
statement numbers 40 and 50 and will 
fall-through to the block started by 
statement number 30 if neither of the 
branches is executed. 





Figure 7. Forward Connection Information 
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Statement Number Entry for 10 


Reordering the Statement Number Chain 


After text blocking, arithmetic transla- 
tion, and, if complete optimization has 
been specified, the gathering of 
constant/variabie usage information have 
been completed, subroutine VSETUP reorders 


the statement number chain of the informa- 
tion table (refer to Appendix A, 
"Information Table"). The original order 


of the entries in this chain, as recorded 
by phase 10, was in the order of the 
occurrence of their associated statement 
numbers as either definitions or operands. 
The new sequence of the entries after 
reordering is according to the occurrence 
of their associated statement numbers as 
definitions only. 


Although the actual 
place after the scan of the phase 10 text, 
preparation for it takes place during the 
scan. As each statement number definition 
is encountered, a pointer to the related 
statement number entry is recorded. Thus, 
during the course of processing, a table of 
pointers to statement number entries, which 
reflects the crder in which statement num- 
bers are defined in the module, is built. 


reordering takes 


PHASE 15 TEXT 


LDF Lei —» 10 


The order of the entries in this table also 
reflects the order of the text blocks of 
the module. 


After the scan, VSETUP uses this table 
to reorder the statement number entries. 
It places the first table pointer into the 
appropriate field of the communication 
table (refer to Appendix A, “Communication 
Table"); it places the second table pointer 
into the chain field of the statement 
number entry that is pointed to by the 
pointer in the communication table; it 
places the third table pointer into the 
chain field of the statement number entry 
that is pointed to by the chain field of 
the statement number entry that is pointed 
to by the pointer in the communication 
table; etc. When VSETUP has performed this 
process for all pointers in the table, the 
entries in the statement number chain are 
arranged in the order in which their asso- 
ciated statement numbers are defined in the 
module. The new order of the chain also 
reflects the order of the text blocks of 
the module. 


Gathering Backward Connection Information 


statement number chain has 
and if optimization has 

subroutine VSETUP gathers 
information. This 


After the 
been reordered, 
been specified, 
backward connection 
information indicates which text blocks 
receive control from which other text 
blocks. Backward connection information is 
used extensively throughout phase 20 opti- 
mization. 


Subroutine VSETUP uses the reordered 
statement number chain and the information 
in the forward connection table (RMAJOR) to 
determine the backward connections. Tt 
records backward connection information in 
a table called CMAJOR. Each CMAJOR- entry 
made by VSETUP for a particular text block 
(block I) is a pointer to the statement 
number entry for a block from which block I 
may receive control. Because each state- 
ment number entry contains a pointer to its 


associated text block (refer to "Text 
Blocking"), each CMAJOR entry for block I 
points indirectly to a block from which 


block I may receive control. 


Subroutine VSETUP gathers backward con- 
nection information for the text blocks 
according to the order of the statement 
number chain; it first determines and 
records the backward connections for the 
text block associated with the initial 
entry in the statement number chain; it 
then gathers the backward connection infor- 
mation for the block associated with the 
second entry in the chain; etc. 
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For each text block, VSETUP initially 
records a pointer to the next available 
entry in CMAJOR in the backward connection 


field (JLEAD) of the associated statement 
number entry (refer to Appendix A, 
"Statement Number/Array Table"). The 


Statement number entry thereby points to 
the first entry in CMAJOR in which the 
backward connection information for the 
block is to be recorded. 


Then, to determine the backward connec- 
tion information for the block (block I), 
VSETUP obtains, in turn, each entry in the 
statement number chain. (The entries are 
obtained in the order in which they are 


chained.) After VSETUP has’ obtained an 
entry, it picks up the forward connection 
field (ILEAD) of that entry. This field 


points to the initial RMAJOR entry for the 
text block associated with the obtained 
Statement number entry. (Recall that the 
RMAJOR entries for a block indicate the. 
blocks to which that block may pass_ con- 
trol.) VSETUP searches ali RMAJOR entries 
for the block associated with the obtained 
entry for a pointer to the statement number 
entry for biock I. If such a pointer 
exists, the text block associated with the 
obtained statement number entry may pass 
control to block I. Therefore, block I may 
receive control from that block and VSETUP 


records a pointer to its associated state- 
ment number entry in the next available 
entry in CMAJOR. VSETUP repeats this pro- 
cedure for each entry in the statement 


number chain. Thus, it searches all RMAJOR 
entries for pointers to the statement num- 
ber entry for block I and records in CMAJOR 
a pointer to the statement number entry for 
each text block from which block I may 
receive control. VSETUP flags the last 
entry in CMAJOR for block I. When the 
statement number chain has been completely 
searched, VSETUP has gathered all the back- 
ward connection information for block I. 
Each entry that VSETUP has made for block 
I, the first of which is pointed to by the 
Statement number entry for block I and the 
last of which is flagged, points indirectly 
to a block from which block I may receive 
control. 


Subroutine VSETUP gathers the backward 
connection information for all blocks in 
the above manner. When all of this infor- 
mation has been gathered, control is 
returned to the FSD, which calls CORAL, the 
third segment of phase 15. 


Figure 8 illustrates the end result of 
the gathering of backward connection infor- 
mation for sample text blocks. Only the 
backward connections for the blocks begin- 
ning with statement numbers 40 and 50 are 
shown. In the figure, it is assumed that: 
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Figure 8. 
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Backward Connection Information 


statement number 
receive control from the execu- 
branch instructions that reside 
blocks started by statement 
10 and 20 and that it may 
control as a result of a fall- 
from the block started by 


statement number 30. 


e The 


resides 


ment number 20 and that it may 


control 


from the 


block 
50 may receive control from the 
tion of 


started by statement number 
execu- 
a branch instruction that 
in the block started by state- 
receive 
as a result of a fall-through 
block started by statement 


number 40. 


CORAL PROCESSING 


CORAL, the last overlay segment of phase 


15, 


performs 


five functions. It first 


converts phase 10 data text to a form more 


easily evaluated by phase 25. 
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assigns addresses relative to the start of 
an object module to all symbolic operands 
~- variables, constants, and arrays. Dur- 
ing the assignment of relative addresses to 
variables, CORAL rechains the data text in 
order to simplify the generation of text 
card images by phase 25. CORAL assigns 
space in the address constant table 
(NADCON) for unknown references -~ calli-by- 
name variables, library routines, and name- 
list names. This reserved space will be 
filled by later phases. Lastly, as a user 
option, CORAL prints a storage map of named 


items -- variables, arrays, and external 
references tae as recorded in the 
information table. (Chart 09 shows the 
overall logic flow of CORAL). 
Translation of Data Text 

The first section of CORAL, subroutine 
NDATA, translates data text entries from 


their phase 10 format to a form more easily 
processed by phase 25. Each phase 10 data 
text entry (except for initial housekeeping 


entries) contains a pointer to a variable 
or constant in the information table. Each 
variable in the series of entries is to be 
assigned to a constant appearing in another 
entry. Placed in separate entries, varia- 
ble and constant appear to be unrelated. 
In each phase 15 data text entry, after 
translation, each related variable and con- 
stant are paired (they appear in adjacent 
fields of the same entry). 


The following example shows how a series 
of phase 10 data text entries are translat- 
ed by NDATA to yield a smaller number of 
phase 15 text entries, with each related 
constant and variable paired. Assume a 
statement appearing in the source module as 
DATA, A,B/2*0/. The resulting phase 10 
text entries appear as follows (ignoring 
the chain, mode, and type fields, and the 
two initial housekeeping entries): 


eee Se ag Rey are Oe Sea ar a ay | 
| Adjective | | 
| Code for: | Pointer | 
po aan an nn fm nnn nnn nm { 
| | Pointer to A | 
| | in dictionary | 
po =a nana =n {-—--—~--——-----——-- { 
| ’ | Pointer to B | 
| | in dictionary | 
[-------------------— a : 
| / {| 2 i 
[-------------------- }---~--------------—- 

| * | Pointer to 0 H 
| | in dictionary | 
}---—-----——-------—- $-———----—---------- { 
| / {| 0 | 
eee Se eae eee ee ee el ee nr ae eo 4 
Note that the variables A and B and the 


constant value 0 appear in separate text 
entries. The NDATA translation of the 
above phase 10 entries (ignoring the con- 
tents of the indicator and chain fields, 
and two optional fields needed for special 
cases) appears as follows: 


 ceaieaarireetaalerrsiees oe 1 
|Indicator| Chain ]P1 Field {P2 Field | 
[-------—-4---------}---=-------—-------- 

| | |pointer | pointer | 
| | jto A in jto 0 in | 
| | |dictionary|dictionary| 
p-------—~ 4--------- }---------= }---------- { 
| | | pointer | pointer | 
| | jto B in jto 0 in | 
| | jatcer onary (dr cetondry| 
ee eee Ma esate thas Maes ay oe ales Dee Sia oat aks 

In this case, each variable and its speci- 
fied constant value appear in adjacent 
fields of the same phase 15 text entry. 
The reader should refer to Appendix B, 
"Phase 15/20 Intermediate Text 
Modification" for the detailed format of 


the phase 15 data text entry and the use of 
the special fields not discussed. 


Relative Address Assignment 


The chief function of CORAL is to assign 


relative addresses to the operands 
(constants and variables) of the source 
module. The addresses indicate the loca- 


tions, relative to zero, at which the 
operands will reside in the object module 
resulting from the compilation. The rela- 
tive address assigned to an operand con- 
sists of an address constant and a dis- 


placement. These two elements, when added 
together, form the relative address of the 
operand. The address constant for an oper- 


and is the base address value used to refer 
to that operand in main storage. Address 
constants are recorded in the adcon table 
(NADCON) and are the elements to which the 
relocation factor is added to relocate the 
object module for execution. The displace- 
ment for an operand indicates the number of 
bytes that the operand is displaced from 
its associated address constant. Displace- 
ments are in the range of 0 to 4095 _ bytes. 
The relative address assigned to an operand 
is recorded in the information table entry 
for that operand in the form of: 


1. A numeric displacement from its asso- 
ciated address constant. 3h 

2. A pointer to an information table 
entry that contains a pointer to the 
associated address constant in the 
adcon table. 


Relative addresses are assigned through 
use of a location counter. This counter is 
initially set to zero and is continually 
updated by the size (in bytes) of the 
operand to which an address is assigned. 
The value of the location counter is used 
tos 


e Contain the displacement to be assigned 
to the next operand. 


e Determine when the next address con- 
stant is to be established. (When the 
location counter achieves a value in 


excess of 4095, a new address constant 
is established.) 


CORAL assigns addresses to source module 
operands in the following order: 

e Constants. 

e Variables. 

e Arrays. 


e Hollerith characters when used as argu- 
ments. 


¢ Equivalenced variables and arrays. 
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e Common variables and arrays, including 
variables and arrays made common using 
the EQUIVALENCE statement. 


The manner in which addresses are assigned 
to each of these operand types is described 
in the following paragraphs. Because con- 
stants, variables, and Hollerith characters 
are processed in the same manner, they are 
described together. 


Constants, Variables, and Hollerith Charac- 
ter Strings Used_as Arguments: Subroutine 
CONST first assigns relative addresses to 
the constants of the module. Then, subrou- 
tine VARA assigns addresses to the varia- 
bles and Hollerith character strings. (In 
the subsequent discussion, constants, vari- 
ables, and Hollerith character strings are 
referred to collectively as operands.) The 
first operand is assigned a displacement of 
zero, which is the initial value of the 
location counter. Operands that are 
assigned locations within the first 4096 


bytes of the object module are not explic- 
itly assigned an address constant. Such 
Operands use the base address value loaded 


into reserved register 12 as their address 
constant (refer to Phase 20, “Branching 
Optimization"). The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated by the size in bytes of the oper- 
and. 


The next operand is assigned a displace- 
ment equal to the current value of the 
location counter. The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated, and tested to see if it exceeds 
4095. If it does not, the next operand is 
processed as described above. 


If sufficient operands exist to cause 
the location counter to achieve a value in 
excess of 4095, the first address constant 
is established. The value of this address 
constant equals the location counter value 
that caused its establishment. This 
address constant becomes the current 
address constant and is saved for subse- 
quently assigned relative addresses. The 
location counter is then reset to zero and 
the next operand is considered. 


constant is 
the address 
addresses 


After the first address 
established, it is used as 
constant portion of the relative 
assigned to subsequent operands. The dis- 
placement for these operands is equal to 
the value of the location counter at the 
time they are considered for relative 
address assignment. 


When the location counter again reaches 


a value in excess of 4095, another address 
constant is established. Its value is 
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equal to the current address constant plus 
the displacement that caused the establish- 
ment of the new address constant. This new 
address constant then becomes current and 
is used as the address constant for subse- 
quent operands. The location counter is 
then reset to zero and the next operand is 
processed. This overall process is repeat- 
ed until all operands (constant, variables, 
and Hollerith strings) are processed. 
Source module arrays are then considered 
for relative address assignment. 


Arrays: Subroutine VARA assigns each array 
of the source module that is not in common 
a relative address that is less than (by 
the span of the array) the relative address 
at which the array will reside in the 
object module. (The concepts of span is 
discussed in Appendix F.) The actual rela- 
tive address at which an array will reside 
in the object module is derived from the 
sum of address constant and displacement 
that are current at the time the array is 
considered for relative address assignment. 
The array span is subtracted from the 
relative address to facilitate subscript 
calculations. 

VARA subtracts the span in one of two 
ways. If the span is less than the current 
displacement, it subtracts the span from 
that displacement, and assigns the result 
as the displacement portion of the relative 
address for the array. In this case, the 
address constant assigned to the array is 
the current address constant. If the span 
is greater than the current displacement, 
VARA subtracts the span from the sum of the 
current address constant and displacement. 
The result of this operation is a new 
address constant, which does not become the 
current address constant. VARA assigns the 
new address constant and a displacement of 
zero to the array. It then adds the total 
Size of the array to the location counter, 
obtains the next array, and tests the value 
of the location counter. If the value of 
the location counter does not exceed 4095, 
VARA does not take any additional action 
before it processes the next array. If the 
location counter value exceeds 4095, VARA 
establishes a new address constant, resets 
the location counter, and processes’ the 
next array. After all arrays have relative 
addresses, VARA returns control to CORAL, 
which calls subroutine EQVAR to assign 
address to equivalence variables and arrays 
that are not in common. 


Equivalence Variables and Arrays Not in 
Common: In assigning relative addresses to 


equivalence variables and arrays, subrou- 
tine EQVAR attempts to minimize the number 
of required address constants by using, if 
possible, previously established address 
constants as the base addresses for equiva- 
lence elements. EQVAR processes equiva- 


lence information on a group-by-group 
basis, and assigns a relative address, in 
turn, to each element of the group. Prior 
to processing, EQVAR determines the base 
value for the group. The base value is the 
relative address of the head? of the group. 
The base value equals the sum of the 
current address constant and displacement 
(location counter value). After EQVAR has 
determined the base value, it obtains the 
first (or next) element of the group and 
computes its relative address. The rela- 
tive address for an element equals the sum 


of the base value for the group and the 
offset of the element. The offset for an 
element is the number of bytes that the 


element is displaced from the head of the 
group (refer to “Common and Equivalence 
Processing"). EQVAR then compares the com- 
puted relative address to the previously 
established address constants. If an 
address constant exists such that the dif- 
ference between the computed relative 
address and the address constant is less 
than 4095, EQVAR assigns that address con- 
stant to the equivalence element under 
consideration. The displacement assigned 
in this case is the difference between the 
computed relative address of the element 
and the address constant. EQVAR then proc-— 
esses the next element of the group. 


If the desired address constant does not 
exist, EQVAR establishes a new address 
constant and assigns it to the element. 
The value of the new address constant is 
the relative address of the element. EQVAR 
then assigns the element a displacement of 
zero, and processes the next element of the 
group. When all elements of the group are 
processed, EQVAR computes the base value 
for the next group, if any. This base 
value is equal to the base value of the 
group just processed plus the size of that 
group. The next group is then processed. 


Common Variables and Arrays: Subroutine 
COMVAR considers each common block of the 


source module, in turn, for relative 
address assignment. For each common block, 
COMVAR assigns relative addresses to (1) 
the variables and arrays of that block, and 
(2) the variables and arrays equivalenced 
into that common block. (The processing of 
variables and arrays equivalenced into com- 
mon is described in a later paragraph.) 


Because common blocks are considered 
separate control sections, COMVAR assigns 
each common block of the source module a 
relocatable origin of zero. It achieves 
the origin of zero by assigning to the 


1The head of an equivalence group is the 
variable in the group from which all other 
variables or arrays in the group can be 
addressed by a positive displacement. 
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first element of a common block a relative 
address consisting of an address constant 
and a displacement whose sum is zero. For 
example, both the address constant and the 
displacement for the first element ina 
block can be zero. Also, the address 
constant can be -16 and the displacement 
+16. Note that the address constant in the 
latter case is negative. Negative address 
constants are permitted, and may be a 
by-product of the assignment of addresses 
to common variables and arrays. They 
evolve from the manner in which the rela- 
tive addresses are assigned to arrays. A 
relative address assigned to an array is 


equal to its actual relative address minus 
the span of that array. The actual rela- 
tive address of each array in a common 


block is equal to the offset computed for 
it during the common and equivalence proc- 
essing of the first segment of phase 15, 
STALL. From the offset of each array in 
the common block under consideration, COM- 
VAR subtracts the span of that array. The 
result then replaces the previously comput- 
ed offset for the array. If the result of 
one or mcre of these computations yields a 
negative value, COMVAR uses the most nega- 
tive as the initial address constant for 
the common biock. It then assigns each 
element (variable or array) in the common 
block a relative address. This address 
consists of the negative address constant 
and a displacement equal to the absolute 
value of the address constant plus the 
offset of the element. 


If the computations which subtract spans 
from offsets do not yield a negative value, 
COMVAR establishes an address constant with 
a value of zero as the initial address 
constant for the common block. It then 
assigns each element in the block a rela- 
tive address consisting of the address 
constant (with zero value) and a displace- 
ment equal to the offset of the element. 


If at any time the displacement to be 
assigned to an element exceeds 4095, COMVAR 
establishes a new address constant. This 
address constant then becomes the current 
address constant and is saved for inclusion 
in subsequently assigned addresses. After 
the new address constant is established, 
the relative address assigned to each sub- 
sequent element consists of the current 
address constant anda displacement equal 
to the offset of that element minus’ the 
value of the current address constant. 
After the entire common block is processed, 
variables and arrays that are equivalenced 
into that common block are assigned rela- 
tive addresses. 


Variables and Arrays Equivalenced into Com- 


mon: Subroutine COMVAR processes variables 
and arrays that are equivalenced into com- 
mon in much the same manner as EQVAR 
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processes those that are equivalenced, but 
not into common. However, in this case, 
the base vaiue for the group is zero. Only 
those address constants established for the 
common block into which the variables and 


arrayS are equivalenced are acceptable as 
address constants for those variables and 
arrays. 


Adcon and Base Variable Assignment: As 
CORAL establishes a new address constant 
and enters it into the adcon table, it also 
places an entry in the information table. 
This special entry, called an "adcon varia- 
ble," points to the new address constant. 
All operands that have been assigned rela- 
tive addresses will have pointers to the 
adcon variable for their address constant. 
The adcon variables generated for operands 
are assigned coordinates, via MCOORD and 
the MVD table. Coordinates 81 through 128 
are reserved for base variables; however, 
some base variables may be assigned coordi- 
nates less than 81 if less than 80 coordi- 
nates are assigned during the gathering of 
variable and constant usage information. 
(Refer to PHAZ15, "Gathering Constant/ 
Variable Usage Information.") Having been 
assigned coordinates, the adcon variables 
are now called base variables. Only those 
operands receiving coordinate assignments 
are available for full register assignment 
during phase 20. 





Rechaining Data Text 


During the assignment of relative 
addresses to variables, subroutine DATACH 
rechains the data text entries. Their 


previous chaining (set by phase 10) was 
according to their order of appearance in 
the source program. DATACH now chains’ the 
data text entries according to the order of 
relative addresses it assigns to variables. 
Thus data text entries are now chained in 
the same relative order in which the varia- 
bles will appear in the object module. 
This order simplifies the generation of 
text card images by phase 25. 


Reserving Space in the Adcon Table 


After relative address assignment is 
completed, subroutine EXTRNL reserves space 
in the adcon table for certain special 
references. It scans the operands of the 
information table to detect any of these 
references: call-by-name variables, names 
of library routines, namelist names, and 
external references. The byte-B usage 
field of each information table entry 
informs EXTRNL if a particular reference 
belongs to one of these categories. For 
each special reference that EXTRNL detects, 
it reserves four bytes in the adcon table. 
Phase 25 places the needed address con- 
stants in the reserved spaces. 
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Producing a Storage Map 


Lastly, aS a user option, subroutine 
STMAP produces a storage map of named 
items. These items include variables, 
arrays, function or subroutine references, 
and statement functions (SF). For each of 
these, except function or subroutine ref- 
erences, the map contains the name, loca- 
tion, type, and tag. (The tag indicates 
whether a variable appeared in a COMMON or 
EQUIVALENCE statement or in both. It is 
set by phase 10 or by CORAL.) For a 
function or subroutine reference the map 
lists the name and whether the reference is 
external or in IFUNTB table. 


PHASE 20 


The primary function of phase 20 is to 
produce a more efficient object module 
(perform optimization). However, even if 
the applications programmer has specified 
no optimization, phase 20 assigns registers 
for use during execution of+ the object 
module. 


For a given compilation, the applica- 


tions programmer may specify no optimiza- 
tion, an intermediate amount of optimiza- 
tion, or complete optimization. Thus, the 


functions performed by phase 20 depena on 
the optimization specified for the compila- 
tion. 


© If no cptimization has been specified, 
phase 20 assigns to intermediate text 
entry operands the registers they will 
require during object module execution 
(this is called basic register 
assignment). As part of this function, 
phase 20 aliso provides information 
about the operands needed by phase 25 
to generate machine instructions. Both 
functions are implemented in a single, 
block-by-block, top-to-pottom (i.e., 
according to the order of the statement 
numper chain), pass over the phase 15 
text output. The end result of this 
processing is that the register and 
status fields of the phase 15 text 
entries are filled in with the informa- 
tion required by phase 25 to convert 
the text entries to machine language 
form (refer to Appendix B, "Phase 20 
Intermediate Text Modifications"). 
Basic register assignment does not take 
full advantage of the available general 


and floating-point registers, and it 
does not specify the generation of 
machine instructions that keep operand 


values in registers (wherever possible) 
for use in subsequent operations 
involving them. 


e If an intermediate amount of optimiza- 
tion has been specified, two processes 
are carried out: 


1. 


The first process, call full reg- 
ister assignment, performs the 
same two functions as basic reg- 
ister assignment. However, full 
register assignment takes greater 
advantage of available registers 
and provides information that ena- 
bles machine instructions to be 
generated that keep operand values 
in registers for subsequent opera- 
tions. An attempt is also made to 
keep the most frequently used 
operands in registers throughout 
the execution of the object 
module. Full register assignment 
requires a number of passes over 
the phase 15 text. The basic unit 
operated upon is the text block 


(refer to phase 15, "Text 
Blocking"). The end result of 
full register assignment, like 


that of basic register assignment, 
is that the register and status 
fields of the phase 15 text 
entries are filled in with the 
information required by phase 25. 


The second process, called branch 
optimization, generates RX-format 
branch instructions in place of 
RR-format branch instructions 
wherever possible. The use of 
RX-format branches eliminates the 
need for an instruction to _ load 
the branch address into a general 
register. However, branch optimi- 
zation first requires that the 
Sizes of all text blocks in the 
module be determined so that the 
branch address can be found. 


e If complete optimization has been spec- 


ified, other measures are taken to 
improve object-module efficiency. Com- 
plete optimization is performed on a 
"loop-by-loop" basis. Therefore, 
before processing can be initiated, 
phase 20 must determine the structure 
of the source module in terms of the 


loops within it and the relationships 


(nesting) 


among the loops. Then phase 


20 determines the order in which loops 


are processed, 
innermost 
loop and proceeding outward. 
optimization 


beginning with the 
(most frequently executed) 
Complete 
general 


involves three 


procedures: 


1. 


The first, called text optimiza- 
tion, eliminates unnecessary text 
entries from the loop being proc- 
essed. For example, redundant 
text entries are removed and, 
wherever possible, text entries 
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are moved to outer loops, where 
they will be executed less often. 


2. The second procedure is full reg- 
ister assignment, which is essen- 
tially the same as in intermediate 
optimization, but is more effec- 
tive, because it is done on a 
loop-by-loop basis. 


3. The final procedure is branching 
optimization, which is the same as 
in the intermediate-optimized 
path. 


CONTROL FLOW 


In phase 20, control flow may take one 
of three possible paths, depending on the 
level of optimization chosen (refer to 
Chart 10). Phase 20 consists of a_ control 
routine (LPSEL) and six routine groups. 
The control routine controls execution of 
the phase. All paths begin and end with 
the control routine. The first group of 
routines performs basic register assign- 
ment. This group is only executed in the 
control path for non-optimized processing. 


The second group performs full register 
assignment. Control passes through this 
group in the paths for both 
intermediate-optimization and complete- 
optimization. The third group of routines 
performs branch optimization and is aiso 
used in the paths for both 
intermediate-optimization and complete- 
optimization. The fourth group determines 
the structure of the source module and is 
used only in the path for 
complet e-optimization. The fifth group 


performs loop selection and again is only 
executed in complete-optimization. The 
final group performs text optimization and 
is only used in complete-optimization. 


The control routine governs the sequence 
of processing through phase 20. The proc- 
essing sequence to _ be followed is deter- 
mined from degree of optimization specified 
by the FORTRAN programmer. If no optimiza- 
tion is specified, the basic register 
assignment routines are brought into play. 
The unit of processing in this path is the 
text block. Each block is passed by the 
control routine to the basic register 
assignment routines for processing. When 
ali blocks are processed, the control rou- 
tine passes control to the FSD, which calis 
phase 25. 


When intermediate-optimization is speci- 
fied, the control routine passes the entire 
module to the full register assignment 
routines and then to the routines that 
compute the size of each text block. When 
all block size information is gathered, the 
control routine calis the routine that 
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computes, using the block size information, 
the displacements required for branching 


optimization. Control is then passed to 
the FSD. 
When the control path for complete 


optimization is selected, the unit of proc- 
essing is a loop, rather than a block. In 
this case, the control routines initially 
pass control to the routines of phase 20 
that determine the structure of the module. 
When the structure is determined, control 
is passed to the loop selection routines, 
to select the first (innermost) loop to be 
processed. The control routines then pass 
control to the text-optimization routines 
to process the loop. When text optimiza- 
tion for a loop is completed, the control 
routine marks each block in the loop as 
completed. This action is taken to ensure 
that the blocks are not reprocessed when a 
subsequent (outer) loop is processed. The 
control routine again passes control to the 
loop selection routines to select the next 
loop for text optimization. This process 
is repeated until text optimization has 
processed each loop in the module. (The 
entire module is the last loop.) ° 


After text optimization has processed 
the entire module, the control routine 
removes the block completed marks and con- 
trol is passed to the loop selection rou- 
tines to reselect the first loop. Control 
is then passed to the full register assign- 
ment routines. When full register assign- 
ment for the loop is complete, the control 
routine marks each block in the loop as 
completed and passes control to the loop 
selection routines to select the next loop. 
This process is repeated for each loop in 
the module. (The entire module is the last 
loop.) When all loops are processed, the 
control routine passes control to the rou- 
tines that compute the size of each text 
block and then to the routine that com- 
putes, using the block size information, 
the displacements required for branching 
optimization. Control is then passed to 
the FSD. 


REGISTER ASSIGNMENT 


Two types of register assignment can be 
performed by phase 20: basic and full. 
Before describing either type, the concept 
of status, which is integrally connected 
with both types of assignment, is dis- 
cussed. 


Each text entry has associated operand 
and base address status information that is 
set up by phase 20 in the status field of 
that text entry (refer to Appendix B, 
“Phase 20 Intermediate Text Modification"). 
The status information for an operand or 
base address indicates such things as 
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whether or not it is 
whether or not it is to be 


in a register and 
retained in a 


register for subsequent use; this informa- 
tion indicates to phase 25 the machine 
instructions that must be generated for 


text entries. 


The relationship of status to 
processing is iliustrated in the following 
example. Consider a phase 15 text entry of 
the form A= B+C. To evaluate the text 
entry, the operands B and C must be added 
and then stored into A. However, a number 
of machine instruction sequences could be 
used to evaluate the expression. If oper- 
and B is ina register, the result can be 
achieved by performing an RX-fornat add of 
C to the register containing B, provided 
that the base address of C is in a reg- 
ister. (If the base address of C is not in 
a register, it must be loaded before the 
add takes place.) The result can then be 
stered into A, again, provided that the 
base address of A is in a register. 


phase 25 


If both B and C are in registers, the 
result can be evaluated by executing an 
RR-format add instruction. The result can 
then be stored into A. Thus, for phase 25 
to generate code for the text entry, it 
must have the status of operands and base 
addresses of the text entry. 


The following facts about status should 


be kept in mind throughout the following 
discussions of basic and full register 
assignment: 


1. Phase 20 indicates to phase 25 when it 
is to generate code that loads oper- 
ands and base adaresses into reg- 
isters, whether it is to generate code 
that retains operands and base 
addresses in registers, and whether 
operand 1 is to be stored. 


2. Phase 20 makes note of the 
and base 
in registers and are 
subsequent use. 


operands 
addresses that are retained 
available for 


Basic Register Assignment 


Basic register assignment involves two 
functions: assigning registers to the cper- 
ands of the phase 15 text entries and 
indicating the machine instructions to be 


generated for the text entries. In per- 
forming these functions, basic register 
assignment does not use all of the availa- 


ble registers, and it restricts the assign- 
ment of those that it does use to special 
types of items (i.e., operands and base 
addresses). The registers assigned during 
basic register assignment and the item(s) 
to which each is assigned are outlined in 
Table 2. 


Table 2. Item Types and Registers Assigned 
in Basic Register Assignment. 

a a aaa eat Sc a aa a aaa ad 1 
j|Register | Item Type | 
}--------~------}------------------------- { 
[Floating-Point | | 
|Register | | 
| | { 
| 0 | Arithmetic text entry| 
| ;operands that are real, | 
| | | 
| 2 | Imaginary part of the| 
| {result of a complex func-| 
| j tion. | 
| | | 
{General Purpose| | 
|Register | | 
| | | 
| 0-1 {Arithmetic text entry | 
| JOperands that are inte-| 
| |ger, or logical operands: | 
| | | 
| 5 | Branch addresses and | 
| |selected logical operands | 
| | 
| 6 |Operands that represent | 
| jindex values | 
| | 
| 7 |Base addresses 
| | | 
| 14 ji. Used for computed GO| 
| | TO Operations, | 
| | | 
| }2. Logical result of | 
| | comparison opera- | 
| | tions | 
| | | 
| 15 {Used for computed GO TO] 
| | Operations. | 
Pi ge a Fe J 

Basic register assignment essentially 
treats System/360 as if it had a single 
branch register, a single base register, 
and a single accumulator. Thus, operands 


that are branch addresses are assigned the 
branch register, base addresses are 
assigned the base register, and arithmetic 
operations are performed using a single 


accumulator. (The accumulator used depends 
upon the mode of the operands to be operat- 
ed upon.) 


The fact that basic register assignment 
uses a Single accumulator and a Singie base 
register is the key to understanding how 
text entries having an arithmetic operator 
are processed. To evaluate the arithmetic 
interaction of two operands using a single 
accumulator, one of the operands must be in 
the accumulator. The specified operation 
can then be performed by using an RX-format 
instruction. The result of tne operation 
is formed in the accumulator and is availa- 
ble for subsequent use. Note that in 
operations of this type, neither of the 
interacting operands remains in a register. 
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Applying this concept to the processing 
of text entries that are arithmetic in 
nature, consider that a phase 15 text entry 
representing the expression A= B+ C is 
the first of the source module. For this 
text entry to be evaluated using a single 
accumulator and base register, basic reg- 
ister assignment must tell phase 25 to 
generate machine code that: 


e Loads the base address of B into the. 
base register. an 


e Loads B into the accumulator. 


e Loads the base address of C into the 
base register. (This instruction is 
not necessary if C is assigned the same 
base address as B.) 


e Adds C to the accumulator (RX-fornat). 


e Loads the base address of A into the 
base register (if necessary). 


e Stores the accumulated result in A. 


If this coding sequence were executed, 
two items woulda remain in registers: the 
last base address loaded and the accumulat- 
ed result. These items are available for 
subsequent use. 


Now consider that a text 
form DB = A + F immediately follows the 
above text entry. In this case, A, which 
corresponds to tne result operand of the 
previous text entry, is in the accumulator. 
Thus, for this text entry, basic register 
assignment specifies code that: 


entry of the 


e Loads the base address of F into the 
base register. (If tne pase address of 
F corresponds to the last loaded base 
address, this instruction is not neces- 
sary.) 


® Adds F to 
add). 


the accumulator (RX-format 


e Loads the base address of D into the 


base register (if necessary). 
® Stores the accumulated result in D. 


The above coding sequences are the basic 
ones specified by basic register assignment 
for arithmetic operations. Tne first is 
specified for text entries in which neither 
operand 2 nor operand 3 (see Figure 5) 
corresponds to the result Operand (operand 
1) of the preceding text entry. The second 
is specified for text entries in which 
either operand 2 or operand 3 corresponds 
to the result operand. If operand 3. cor- 
responds to the result operand, the two 
operands exchange roles, except for divi- 


Discussion of Major Components Wy 


sion. In the case of division, operand 3 
is always in main storage. 


If both operands 2 and 3 correspond to 
the result operand of the previous text 
entry, an RR-format Operation is specified 
to evaluate the interactions of the oper- 
ands. 


In the actual process of basic register 
assignment, a Single pass is made over the 
phase 15 text output. The basic unit 
Operated upon is’ the text block. As the 
processing of each block is completed, the 
next is processed. When ail blocks are 
processed, control is returned to the FSD. 


Text blocks are processed in a top-to- 
bottom manner, beginning with the first 
text entry in the block. When ail text 
entries in a block are processed, the next 
text block is processed similarly. 


For any text entry, the machine code to 
be generated is first specified by setting 
up the status field of the text entry. 
Registers are then assigned to the operands 
and base addresses by filling in the 
register fields of the text entry. 


Status Setting: Subroutine SSTAT sets’ the 
operand and base address status information 
for a text entry in the following order: 
operand 2, operand 2 base address, operand 
3, operand 3 base address, operand 1, and 
operand 1 base address. 


To set the status of operand 2, SSTAT 
determines the relationship of that operand 
to the result operand (operand 1) of the 
previous text entry. If operand 2 is’ the 
Same as the resuit operand, SSTAT sets the 
status of operand 2 to indicate that it is 
in a register and, therefore, need not be 
loaded; otherwise, it sets the status to 
indicate that it is in main storage. SSTAT 
uses a Similar procedure to set the status 
of operand 3. 


To set the status of the base address of 
Operand 2, SSTAT determines the relation- 
Ship of that base address to the current 
base address (see note). If they corre- 
spond, SSTAT sets the status of the base 
address of operand 2 to indicate that it is 
in a register and, therefore, need not be 
loaded; otherwise wise, it sets the status 
to indicate that it is in main storage. 


SSTAT sets the statuses of the base 
addresses of operands 3 and 1 ina similar 
manner. 


The current base address is the last 
base address loaded for the purpose of 
referring to an operand. This base address 
remains current until a subsequent operand 
that has a different base address is 


Note: 
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encountered. When this occurs, the base 
address of the subsequent operand must be 
loaded. That base address then becomes the 
current base address, etc. 


SSTAT sets status of operand 1 to indi- 
cate whether or not the result of the 
interaction of operands 2 and 3 is to be 
stored into operand 1. If operand 1 is 
either an actual operand or a temporary 
that is not used in the subsequent text 
entry, it sets the status of operand 1 to 
indicate that the store is to be performed; 
otherwise; it sets the status to indicate 
that a store into operand 1 is unnecessary. 


Register Assignment: After the status 
field of the text entry is completed, 
subroutine SPLRA assigns registers to the 
operands of the text entry and their asso- 
Ciated base addresses in the same order in 


which statuses were set for them. 


The assignment of registers depends upon 
the statuses of the operands of the text 
entry. To assign a register to operand 2, 
SPLRA examines the status of that operand, 
and, if necessary, of operand 3. If the 
status of operand 2 indicates that it is in 
a register or if the statuses of operands 2 
and 3 indicate that neither is a register, 
SPLRA assigns operand 2 a register. It 
selects the register according to the type 
of operand (refer to Table 2), and places 
the number of that register into the R2 
field of the text entry. 


To assign a register to the base address 
of operand 2, SPLRA determines the status 
of operand 2. If the status of that 
operand indicates that it is not ina 
register, it assigns a register to the base 
address of operand 2. The appropriate 
register is selected according to Table 2, 
and the register number is placed into the 
B2 field of the text entry. If the status 
of operand 2 indicates that it is in a 


register, SPLRA does not assign a register 
to the base address of operand 2. SPLRA 
uses a similar procedure in asSigning a 


register to the base address of operand 3. 


If the status of operand 3 indicates 
that it is in a register, SPLRA assigns the 
appropriate register (refer to Table 2) to 
that operand, and enters the number of that 
register into the R3 field. 


Operand 1 is always assigned a register. 
SPLRA selects the register according to the 
type of operand 1 (refer to Table 2), and 
places the number of that register into the 
R1 field. 


The base address of operand 1 is 
assigned a register only if the status of 
operand 1 indicates that it is to be stored 
into. If such is the case, SPLRA selects 


the appropriate register, and records’ the 
number of that register in the Bi field. 
If the status of operand 1 indicates that 
it is not to be stored into, SPLRA does not 
assign a register to the base address of 
operand 1. 


When all the operands of the text entry 
and their associated base addresses are 
assigned registers, the next text entry is 
obtained, and the status setting and reg- 
ister assignment processes are repeated. 
After all text entries in the block are 
processed, control is returned to the con- 
trol routine of phase 20, which then makes 


the next block available to the basic 
register assignment routines. When the 
processing of all blocks is completed, 


control is passed to the FSD. 


Full Register Assignment 


During full register 
refer to "Full Register Assignment During 
Complete Optimization"), as during basic 
register assignment, registers are assigned 
to the text entry operands and their asso- 
ciated base addresses, and the machine code 
to be generated for the text entries is 
specified. To improve object module effi- 
ciency, these functions are performed in a 
manner that reduces the number of instruc- 
tions required to load base addresses and 
operands. This process reduces the number 
of required load instructions by taking 
greater advantage of all available reg- 
isters, by assigning the registers as need- 
ed to both base addresses and operands, by 
keeping as many operands and base addresses 
aS possible in registers and available for 
subsequent use, and by keeping the most 
active base addresses and operands in reg- 
isters where they are available for use 
throughout execution of the entire object 
module. 


asSignment (also 


During full register assignment, reg- 
isters are assigned at two levels: 
"locally" and "globally." Local assignment 
is performed on a_ block-by-block basis. 
Global assignment is performed on the basis 
of the entire module (if intermediate- 
optimization has been specified). 


For local assignment, an attempt is made 
to keep operands whose values are defined 
within a block in registers and available 
for use throughout execution of that block. 
This is done by assigning an available 
register to an operand at the point at 
which its value is defined. (The value of 
an operand is defined when that operand 
appears in the operand 1 position of a text 
entry.) The same register is assigned to 
subsequent uses (i.e., Operand 2 or operand 
3 appearances) of that operand within the 
block, thereby ensuring that the value of 
the operand will be in the assigned reg- 
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ister and available for use. However, if 
more than one subsequent use of the defined 


Operand occurs in the block, additional 
steps must be taken to ensure that the 
value of that operand is not destroyed 


between uses. Thus, when the text entries 
in which the defined operand is used are 
processed, the code specified for them must 
not destroy the contents of the register 
containing the defined operand. 


Because all available registers are used 
during full register assignment, a number 
of operands whose values are defined within 
the block can be retained in registers at 
the same time. . 


Applying the above concept to an exam- 


ple, consider the following sequence of 
phase 15 text entries; 

A=xX + ¥Y 

C=A+t+Z 

F=A+C 


A register is assigned to A at the point at 
which its vaiue is defined, namely in the 
text entry A= X + Y. The same register is 
assigned to the subsequent uses of A. The 
value of A will be accumulated in the 
assigned register and can be used in the 
subsequent text entry C = At Z. However, 
because A is also used in the text entry 
F=A+C, the contents of the register 
containing A cannot be destroyed by the 


code generated for the text entry 
C=A+t+ Z. Thus, when the text entry C=A 
+ -Z is processed, instructions are speci- 


fied for that text entry that use the 
register containing A, but that do not 
destroy the contents of that register. 

In the example, C is also defined and 
supsequently used. To that defined operand 
and its subsequent uses, a register is 
assigned. The assigned register is differ- 
ent from that assigned to A. The value of 
C will be accumulated in the assigned 
register and can be used in the next text 
entry. The text entry F = A + C can then 
be evaluated without the need of any load 


Operand instructions, because both the 
interacting operands (A and C) are in 
registers. 


This type of processing typifies that 
performed during local assignment for each 
block. When alli blocks are processed, 
global assignment for the source module is 
carried out. 


Global assignment increases the effi- 
ciency of the object module as a whole by 
assigning registers to the most active 
operands and base addresses. The activi- 
ties of all operands and base addresses are 
computed prior to global assignment. The 
first register available for global assign- 
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ment is assigned to the most active operand 
or base address; the next available reg- 
ister is assigned to the next most active 
operand or base address; etc. As each such 
operand or base address is processed, a 
text entry, the function of which is to 
load the operand or base address into the 
assigned register, is generated and placed 
into the first block (i.e., entry block) of 
the module. When the supply of operands 
and base addresses, or the supply of avail- 
able registers, is exhausted, the process 
is terminated. 


All global assignments are recorded for 
use in a subsequent text scan, which incor- 
porates global assignments into the text 
entries, and completes the processing of 
operands that have neither been locally or 
globally assigned to registers (e.g., an 
infrequently used operand that is used ina 
block but not defined in that block). 


The full register assignment process is 
divided into five areas of operation: con- 
trol (subroutine REGAS), table building 
(subroutine FWDPAS), local assignment 
(subroutine BKPAS), global assignment 
(subroutine GLOBAS), and text updating 
(subroutine STXTR). The control routine of 
phase 20 (LPSEL) passes control to the full 
register assignment control routine, which 
directs the flow of control among the other 
full register assignment routines. 


The actual assignment of registers is 
implemented through the use of tables built 
by the table-building routine, with assis- 
tance from the control routine. Tables are 
built using the set of coordinate numbers 
and associated dictionary pointers created 
by phase 15 (MCOORD and MVD) for indexing. 
The table-building routine constructs two 
sets of parallel tables. One set, used by 
the local assignment ‘routine, contains 
information about a text block; the second 
set, used by the global assignment rou- 
tines, contains information about the 
entire module. (The local assignment and 
global assignment tables are outlined in 
Appendix A, “Register Assignment Tables.") 


The flow of control through the full 
register assignment routines is as follows: 


1. The control routine (REGAS) makes a 
pass over the MVD table and the dic- 
tionary entries for the variables and 
constants in the loop passes to it, 
and constructs the eminence table 
(EMIN) for the module, which indicates 
the availability of the variables for 
globai assignment. The routine then 
calls the table-building routine to 
process the first block in the module. 


(FWDPAS) 
of local 


2. The table-building routine 
builds the required set 


ay 


assignment tables for the block and, 
at the same time, adds information to 
the global assignment tables under 
construction. It then passes control 
to the local assignment routine to 
process the block. When processing of 
the block is completed, control is 
returned to REGAS. 


3. The local assignment routine (BKPAS) 
uses the tables supplied for the block 
to perform local register assignment, 
and returns control to FWDPAS when its 
processing is completed. 


4. The control routine (REGAS) selects 
the next block in the module, and 
passes it to the table-building rou- 
tine, which then passes control to the 
local assignment routine. This proc- 
ess continues until all blocks in the 
module have been processed by the 
table-building and local assignment 
routines. 


5. The control routine passes control to 
the global assignment routine, which 


performs global assignment for the 
module. 

6. When global assignment is complete, 
the control routine calls the text 
updating routine (STXTR) to complete 


register assignment by entering the 
results of global assignment into the 
text entries for the module. Control 
is then returned to the control rou- 
tine of phase 20 (LPSEL). 


Table Building for Register Assignment: 
The table-building routine performs a_ for- 


ward scan of the intermediate text entries 


for the block under consideration and 
enters information about each text entry 
into the local and global tables (refer to 


Appendix A, “Register Assignment Tables"). 
The local assignment tables can accommodate 
information for 100 text entries. Ifa 
block contains more than 100 text entries, 
the table-building routine builds the local 


tables for the first 100 text entries and 
passes this set of tables to the local 
assignment routine. The local assignment 


routine processes the text entries rep- 
resented in the set of local tables. The 
table-building routine then creates’ the 
local tables for the next 100 text entries 


in the block and passes them to the local 
assignment routine. When the table- 
building routine encounters the last text 


entry for the block, it passes control to 
the local assignment routine, although 
there may be fewer than 100 entries in the 
local tables. 


The global tables contain information 
relating to variables and constants 
referred to within the module, rather than 


to text entries. The global tables’ can 
accommodate information for 126 variables 
and constants in a given module. Variables 
and constants in excess of this number 
within the module are not processed by the 
global assignment routine. 
Local Assignment: Local assignment is 
implemented via a backward pass over the 
text items for the block (or portion of a 
block) under consideration. The text items 
are referred to by using the local assign- 
ment tables, which supply pointers to the 
text items. 


The local assignment routine examines 
each operand in the text for a block and 
determines (from the local assignment 
tables) if the operand is eligible for 


local assignment. To be eligible, an oper- 
and must be defined and used (in that 
order) within a block. Because local 
assignment is performed via a backward pass 
over the text, an eligible operand will be 
encountered when it is used (i.e., in the 
operand 2 or 3 position) before it is 
defined. 

When an operand of a text entry is 
examined, the local assignment routine 
(BKPAS) consults the local assignment 
tables to determine that operand's eligi- 
bility. If the operand is eligible, BKPAS 
assigns a register to it. The register 
assigned is determined by consulting the 
register usage table (TRUSE). TRUSE is a 
work table that contains an entry for every 
register that may be used by the local 
assignment routine. A zero entry for a 
particular register indicates that the reg- 
ister is available for local assignment. A 
nonzero entry indicates that the register 
is unavailable and identifies the variable 
to which the register is assigned. The 
register usage table is modified each time 
a register is assigned or freed. 


BKPAS records the register assigned to 
the used operand in the local assignment 


tables and in the text item containing the 
used operand. It sets the status of the 
operand in the text entry to indicate that 


it is in a register. If subsequent uses of 
the operand are encountered prior to the 
definition of the operand, BKPAS uses the 
register assigned to the first use, and 
records its identity in the text item. It 
then sets the status bits for the operand 
to indicate that it is in a register and is 
to be retained in that register. 


When a definition of the operand is 
encountered, BKPAS enters the register 
assigned to the operand into the text item 
and sets the status for the operand to 
indicate its residence in a register. Once 
the register is assigned to the operand at 
its definition point, BKPAS frees the reg- 
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ister by setting the entry in the register 


usage tabie to zero, making the register 
available for assignment to another oper- 
and. 


If the block being processed contains a 
CALL statement, no common variables may be 
considered for local assignment and no real 
operands can be assigned to registers 
across that reference. In addition, if the 
block contains a reference to a function 
subprogram, no local assignment may be made 
for real operands across the reference to 
that function. The local assignment rou- 
tine assumes that: 


1. All mathematical functions return the 
result in general register 0 or 
floating-point register 0, according 
to the mode of the function. 


2. The imaginary portion of a 
result is 
register 2. 


complex 
returned in floating-point 


If no register is available for assign- 
ment to an eligible operand, an overflow 
condition exists. In this case, BKPAS must 
free a previously assigned register for 
assignment to the current operand. It 
scans the local assignment tables and se- 
lects a register. It then modifies the 
local assignment tables, text entries for 
the block, and register usage table to 
negate the previous assignment of the 
selected register. The required register 
is now available, and processing continues 
in the normal fashion. 


Global Assignment: The global assignment 
routine (GLOBAS), unlike the local assign- 
ment routine, does not process any of the 
text entries for the module. The global 
assignment routine operates only through 
the set of global tables. The results of 
global assignments are entered into the 
appropriate text entries by the text updat- 
ing routine. 


Before assigning registers, the global 
assignment routine modifies the glopnal 
assignment tables to produce ae single 
activity table for all operands and base 
addresses in the module. 

Global assignment is then performed 
based on the activity of the eligible 


operands and base addresses. 


GLOBAS determines the eligibility of an 
operand or base address by consulting the 
appropriate entry in the global assignment 
tables. Eligible operands are divided into 
two categories: floating point and fixed 
point. The two categories are processed 
separately, with floating-point quantities 
processed first. 
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A register usage table (RUSE) of the 
same type as described under local assign- 


ments (TRUSE) is used by the global assign- 
ment routine. For each category of oper- 
ands, GLOBAS selects. the eligible operand 
with the highest total activity and assigns 
it the first available register of the same 
mode. It records the assignment in the 
register usage table and in the global 
assignment tables. GLOBAS then selects the 
eligible operand with the next highest 
activity and treats it in the same manner. 
Processing for each group continues until 
the supply of eligible operands or the 
supply of available registers is exhausted. 


If the module contains any CALL state- 
ments, real and common variables are ineli- 
gible for global assignment. If the module 
contains any references to function subpro- 
grams no global assignment can be performed 
for real quantities. In other words, if a 
module contains both a reference to a 
subroutine and to a function subprogram, 
global assignment is restricted to integer 
and logical operands that are not in com- 
mon. 


Text Updating: The text updating routine 
(STXTR) completes full register assignment. 
It scans each text entry within the series 
of blocks comprising the module, looking at 
operands 2, 3, and i, in that order, within 
each text entry. As each operand is proc- 
essed, STXTR interrogates the completed 
global assignment table to determine if a 


global assignment has been made for the 
operand. If it has, STXTR enters’ the 
number of the register assigned into the 


text entry and sets the operand status bits 
to indicate that the operand is in a 
register and is to be retained in that 
register. 


If both a local and a global assignment 
have been made for an operand, the global 
assignment supersedes the iocal assignment 
and STXTR records the number of the global- 
ly assigned register in the text items 
pertaining to that operand. It also. sets 
the status bits for such an operand to 
indicate that it is in a register and is to 
be retained in that register. 


If a register has not been assigned 
either locally or globally for an operand, 
STXTR determines and records in the text 
entry the required base register for the 
base address of that operand. If the base 
address corresponds to one that has been 
assigned a register during global assign- 
ment, STXTR assigns the same register as 
the base register for the operand. If a 
register has not been assigned to the base 
address of the operand during global 
assignment, it assigns a spill register 
(register 0 or 15) as the base register of 
the operand. STXTR sets the operand's base 
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status bits to indicate whether or not the 
base address is ina register. ‘(The base 
address will be in a register if one was 
assigned to it during global assignment.) 
It then assigns the operand itself a_ spill 
register (general register 0 or 1 or 
floating-point register 0, depending upon 
its mode). 


As part of its text updating function, 
STXTR allocates temporary storage where 
needed for temporaries that have not been 
assigned to a register, keeps track of the 
allocated temporary storage, and completes 
the register fields of text entries to 
ensure compatibility with phase 25. On 
exit from the text updating routine, all 
text items in the module are fully formed 
and ready for processing by phase 25. The 
text updating routine returns control to 
the full register assignment control rou- 
tine (REGAS) upon completion of its func- 
tions. REGAS, in turn, returns control to 
the control routine of the phase (LPSEL). 


BRANCHING OPTIMIZATION 


This portion of phase 20 optimizes 
branching within the object module. The 
optimization is achieved by generating RX- 
format branch instructions in place of 
RR-format branch instructions wherever 
possible. 


The use of RX-format branches eliminates 
the need for an instruction to load the 
branch address into a general register 
preceding each branching instruction. 
Thus, branching optimization decreases the 
Size of the object module by one instruc- 
tion for each RR-format branch instruction 
in the object module that can be replaced 
by an RxX-format branch instruction. It 
also decreases the number of address con- 
Stants required for branching. 


Phase 20 optimizes branching instruc- 
tions by calculating the size of each text 
block (number of bytes of object code to be 
generated for that block) and by determin- 
ing those blocks that can be branched to 
via RX-format branch instructions. 


Subroutine BLS calculates the sizes of 
all text blocks after full register assign- 
ment for the module is completed. Subrou- 
tine LYT then uses the gathered block size 
information to determine the blocks’ that 
can be branched to by means of RX-format 
branch instructions. BLS calculates’ the 
number of bytes of object code by: 


1. Examining each text item operation 
code and the status of the operands 
(i.e., in registers or not). 


2. Determining, from a reference table, 
the number of bytes of code that is to 
be generated for that text item. 


BLS accumulates these values for each block 
in the moduie. In addition, it increments 
the block size count by the appropriate 
number of bytes for each encountered ref- 
erence to an in-line routine and for each 
required prologue and epilogue, if a sub- 
program program is being compiled (refer to 


Phase 255 “Prologue and Epilogue 
Generation"). 
After BLS computes all block sizes, 


subroutine LYT determines those text biocks 
that can be branched to via RxX-format 
branch instructions. A text block, once 
converted to machine code, can be branched 
to via an RX-format branch instruction if 
the relative address of the beginning of 
that block is displaced less than 4096 
bytes from an address that is loaded into a 
reserved register. 


The following text discusses reserved 
registers, the addresses loaded into them, 
and the processing performed by LYT to 
determine the source module blocks that can 
be branched to via RxX-format branch 
instructions. 


Reserved Registers 


Reserved registers are allocated to con- 
tain the starting address of the adcon 
table and subsequent 4096-byte blocks of 
the object module. The criterion used by 
phase 20 in reserving registers for this 
purpose is the number of text entries that 
result from phase 15 processing. (Phase 15 
counts the number of text entries that 
result from its processing and passes’ the 
information to phase 20.) For relatively 
small source modules (approximately 70 
source statements), phase 20 reserves only 
one register. For sufficiently large 
source modules (approximately 280 source 
statements), a maximum of four is reserved. 
The registers are reserved, as needed, in 
the following order: register 13, 11, 10, 
and 9. 


Note: Phase 20 also reserves register 12 
to contain the relative address of the 
“constants" portion of text information 


(see Figure 11). It is used to refer to 
the constants and/or variables that occupy 
locations within the first 4096 bytes of 
the text information portion of the object 
module. 


Reserved Register Addresses 


The addresses placed into the reserved 
registers as a result of the execution of 
the initialization instructions (refer to 
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Phase 25, “Initialization Instruction") 
are: 
e Register 13 - address of main prcgram 


(or subprogram) save area.1 
e Register 11 (if reserved) - address of 
the save area plus 4096. 


e Register 10 (if reserved) - address of 

the save area plus 2(4096). 
e Register 9 (if reserved) - address of 
the save area plus 3(4096). 


Block Determination and Subsequent 
Processing 


Because the instructions resulting from 
the compilation are entered into text 
information immediately after the adcon 
table (see Figure 11), certain text blocks 
are displaced iess than 4096 bytes from an 
address in a reserved register. Such 
blocks can be branched to by RxX-format 
branch instructions that use the address in 
a reserved register as the base address for 
the branch. 


To determine the blocks that can be 
branched to via RX-format branch instruc- 
tions, subroutine LYT computes the dis- 
placement (using the block size 
information) of each biock from the address 
in the appropriate reserved register. The 
first reserved register address considered 
is that in register 13. If a block dis- 
placed iess than 4096 bytes from that 
address exists, LYT enters the displacement 
of that block (from the address) into the 
statement number entry for the statement 
number associated with the beginning of 
that biock. It aiso places in that state- 
ment number entry an indication that the 
block can be transferred to via an RX- 
format branch instruction, and records the 
number of the reserved register to be used 
in that branch instruction. 


When LYT has processed all blocks 
displaced less than 4096 bytes from the 
address in register 13, it processes those 


G@isplaced less than 4096 bytes from the 
addresses in registers 11, 10, and 9 (if 
reserved) in a Similar manner. 


The information placed in the statement 
number entries is used during code genera- 
tion, a phase 25 process, to generate 
RX-format branch instructions. 


1Register 13 is used to refer to the adcon 
table, which resides in text information 
immediately after the initialization 


instructions (see Figure 11). 
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STRUCTURAL DETERMINATION 


To achieve complete optimization, the 
structural determination routines of phase 
20 (TOPO and BAKT) identify module loops 
and specify the order in which they are to 
be processed. Loops are identified by 
analyzing the block connection information 
gathered by phase 15 and recorded in the 
forward connection (RMAJOR) and backward 
connection (CMAJOR) tables. The connection 
information indicates the flow of control 
within the module and, therefore, reflects 
which blocks pass control among themselves 
in a cyclical fashion. 


Loops are ordered for processing start- 
ing with the innermost, or most often 
executed, loop and working outward. The 


inner-to-outer loop sequence is specifed so 
that: 


e Text entries will not be relocated into 
Loops that have already been 
processed.?+ 


e The full 
System/360 
most frequently 
loop. 


register capabilities of 
can first be applied to the 
executed (innermost) 


identification is a sequential 
process, which first requires that a back 
dominator be determined for each text 
block. The back dominator of a text block 
(block I) is defined as the block nearest 
to block I through which control must pass 
before block I receives control for the 
first time. The back dominators of all 
text blocks must be determined before loop 
identification can be continued. After all 
back dominators have been determined, a 


Loop 








chain of back dominators is effectively 
established for each block. This chain 
consists of the back dominator of the 


block, the back dominator of the back 


dominator of the block, etc. 


Figure 9 illustrates the concept of back 
dominators. Each block in the figure rep- 
resents a text block. The blocks are 
identified by single letter names. The 
back dominator of each block is identified 
and recorded above the upper right-hand 
corner of that block. 


When all back dominators are identified, 


a back target and a depth number for each 
1The text optimization process relocates 


text entries from within a loop to an outer 
loop. Thus, if an outer loop were proc- 
essed first, text entries from an inner 
loop might be relocated to the outer loop, 
thereby requiring that the outer loop be 
reprocessed. 


48 


text block are determined. A block (block 
I) has a back target (block J) if: 


e There exists a path from block I to 
itself that does not pass through block 
J. 


e Block J is the nearest block in the 
chain of back dominators of block I 
that has only one forward connection. 


The 
identifiable because 
back target, known 
the loop. 


text blocks constituting a loop are 
they have a common 
as the back target of 


The depth number for a block indicates 
the degree to which that block is nested 
within loops. For example, if a block is 
an element of a loop that is contained 
within a loop with a depth number of one, 
that block has a depth number of two. All 
blocks constituting the same loop (i.e., 
all blocks having a common target) have the 
Same depth number. Entry 





Exit 


Figure 9. Back Dominators 

The depth numbers computed for the 
blocks that comprise the various loops are 
used to determine the order in which the 
loops are to be processed. 


Figure 10 illustrates the concepts of 
back targets and depth numbers. Again each 
block in the figure represents a text 
block, which is identified by a single 
letter name. In this figure, the back 
target of each block is identified and 


recorded above the upper right-hand corner 
of that block. The depth number for the 
block is recorded above the upper left-hand 
corner of the block. Note that blocks that 
pass control among themselves ina looping 
fashion have a common back target and the 
same depth number. Also note that the 
blocks of the two inner loops have the same 
depth numbers, although they have different 
back targets. 


When the back target and depth number of 
each text block has been determined, loops 
are identified and the order in which they 
are to be processed is specified. The 
loops are ordered according to the depth 
number of their blocks. The loop whose 
blocks have the highest depth number is 
specified as the first to be processed; the 
loop whose blocks have the next highest 
depth number is specified as the second to 
be processed; etc. When the processing 
order of all loops has been established, 
the innermost loop is selected for process- 
ing. 


describe the 
structural 


The following paragraphs 
processing performed by the 
determination routines to: 


e Determine the back dominator of each 
text block. 
e Determine the back target and depth 


number of each text block. 
e Identify and order loops 
ing. 


for process- 


Entry 
0 0 





Exit 


Figure 10. Back Targets and Depth Numbers 
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Determination of Back Dominators 


Subroutine TOPO determines the back dom- 
inator of each text block by examining the 
connection information for that block. The 
first block processed by TOPO is the first 
block (entry block) of the module. Blocks 
on the first level (i.e., blocks that 
receive control from the entry block) are 
processed next. Second-level blocks (i.e., 
blocks that receive control from first- 
level blocks) are then processed, etc. 

TOPO assigns the entry block a back 
dominator of zero, because it has no back 
dominator; it records the zero in the back 
dominator field of the statement number 
entry for that block (refer to Appendix A, 
"Statement Number/Array Table"). TOPO 
assigns each block on the first level 
either its actual back dominator or a 
provisional back dominator. If a first- 
level block receives control from only one 
block, that block must be the entry block 
and is the back dominator for the first- 
level block. TOPO records a pointer to the 
statement number entry for the entry block 
in the back dominator field of the 
statement number entry for the first level- 
block. If a first-level block receives 
control from more than one biock, TOPO 
assigns it a provisional back dominator, 
which is the entry block of the module. 
All blocks on the first level are processed 
in this manner. 


TOPO also assigns each block on the 
second level either its actual back 
dominator or a provisional back dominator. 
If a second-level block receives control 
from only one block, its back dominator is 


the first-level block from which it 
receives control. TOPO records a pointer 
to the statement number entry for the 
first-level block in the back dominator 


field of the statement number entry for the 
second-level biock. If more than one block 
passes control to a second-level biock, 
TOPO assigns that block a provisional back 
dominator. The provisional back dominator 
assigned is a first-level block that passes 
control to the second-level block under 
consideration. Processing cf this type is 
performed at each level until the last, or 
exit, block of the module is processed. 
TOPO then determines the actual back domi- 
nators of blocks that were assigned provi- 
sional back dominators. 


For each block assigned a provisional 
back dominator, subroutine TOPO makes a 
backward trace over each path leading to 
the block (using CMAJOR). The blocks at 
which two or more of the paths converge are 
flagged as possible candidates for the back 
dominator of the _ block. When ail paths 
have been treated, the relationship of each 
possible candidate to the other possibile 
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candidates is examined. TOPO assigns the 
candidate at the highest level (i.e., clos- 
est to the entry block of the module) as 
the back dominator of the block under 
consideration; it records a pointer to the 
statement number entry for the assigned 
back dominator in the back dominator field 
of the statement number entry for the block 
under consideration. After the back domi- 
nators of all text blocks are identified, 
subroutine BAKT determines the back target 
and depth number of each text block. 


Determination of Back Targets and Depth 
Numbers 


Subroutine BAKT determines the back tar- 
get of each text block through an analysis 
of the backward connection infcrmation (in 
CMAJOR) for that block. Block J is the 
back target of block I if: 


1. Block J is’ the nearest block in the 
chain of back dominators of block I. 


2. Block J has only one forward connec- 
tion. 

3. There exists a path from block I to 
itself that does not pass’ through 
block J. 

If a block J exists that satisfies ail 


the above conditions except the second, 
then the back target of block J is also the 
back target of block I. 


If a block J satisfying conditions 1 and 
3 does not exist, then the back target of 
block I is zero. 


When the 
identified, 
depth number. 


back target of a block is 
that block is also assigned a 


Back targets and depth numbers are de- 
termined for text blocks in the same order 
as back dominators are determined for them. 
The first block of the module is the first 
processed; first-level blocks are consid- 
ered next; etc. 


BAKT assigns the first or entry block 
both a back target and depth number of 
zero, because it does not have ae back 
target and is not ina loop. It records 
the depth number (zero) in the loop number 
field of the statement number entry for the 
entry biock (refer to Appendix A, 
“Statement Number/Array Table"). 


The processing performed by BAKT for 
each other block depends upon whether one 
or more than one block passes control to 
that block. If more than one block passes 
control to the block under consideration, 
BAKT makes a backward trace over ail paths 
leading to that block to locate its primary 
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path. The primary path of a block (if one 
exists) is a path that starts at that block 
and converges on that block without passing 
through any block in the chain of back 
dominators of that block. 


If such a path exists, BAKT obtains and 
examines the nearest block in the chain of 
back dominators of the block under consid- 


eration. If the obtained block has a 
Single forward connection, BAKT assigns 
that block as the back target of the block 
under consideration. BAKT then assigns a 


depth number to the block. The number is 
one greater than that of its back target, 
because the block is in a loop, which must 
be nested within the loop containing the 
back target. BAKT records the depth number 
in the loop number field of the statement 
number entry for the block. 


If the obtained block has more than one 
forward connection, BAKT assigns its back 
target as the back target of the biock 
under consideration. BAKT then records in 
the statement number entry for the biock a 
depth number one greater than that of its 
back target. 


If a block that receives control from 
two or more blocks does not have an asso- 
ciated primary path, that block, if it is 
in a loop at all, is in the same loop as 


one of the blocks in its chain of back 
dominators. To identify the loop contain- 
ing the block (block I), BAKT obtains and 


examines the nearest block to block I in 
its chain of back dominators tnat has two 
or more forward connections. BAKT makes a 
backward trace over all paths leading to 
the ontained block to determine whether or 
not block I is an element of such a path. 
If block I is an element of such a path, it 
is in the same loop as the obtained block, 
and BAKT therefore assigns block I the sane 
back target and depth number as the 
obtained block; it records the depth number 
in the statement number entry for block I. 


If block I is not an element of any path 
leading to the obtained block, BAKT obtains 
the next nearest block to biock I in its 
chain of back dominators that has two or 
more forward connections and repeats’ the 
process. If block I is not an element of 
any path leading to any block in its chain 
of back dominators, block I is not ina 
loop, and BAKT assigns it both a _ back 
target and depth number of zero. 


A block that receives control from only 
one block, if it is in a loop at all, is in 
the same loop as one of the blocks in its 
chain of back dominators. To identify the 
loop containing a block (block I) that 
receives control from only one block, BAKT 
obtains and examines the nearest block to 
block I in its chain of back dominators 


that receives control from two or mcre 
blocks. BAKT makes a backward trace over 
all paths leading to the obtained block to 
locate its primary path (if any). If the 
obtained block has a primary path, BAKT 


retraces it to determine if block I is an 
element of the path. If it is, block I is 
in the same loop as the obtained block, 


and, BAKT therefore assigns block I the 
same back target and depth number as the 
obtained block; it records the depth number 


in the statement number entry for block I. 


If the obtained biock does not have a 
primary path, or if it does have a primary 
path, which, however, does not have block I 
as an element, BAKT considers the next 
nearest block to block I in its chain of 
back dominators that receives control from 
two or more blocks. The process is repeat- 
ed until a primary path containing block I 
is located (if any such path exists). If 
block I is not in the primary path of any 
block in its chain of back dominators, 
block I is not in a loop and BAKT assigns 
it both a back target and depth number of 
zero. 


Identifying and Ordering Loops for 
Processing 


Subroutine BAKT orders blocks for  proc- 
essing on the basis of the determined back 
target and deptn number information. 


Blocks that have a common back target and 
the same depth number constitute a loop. 
BAKT flags the loop with the highest depth 
number (therefore, the most deeply nested 
loop) as the first loop to be processed. 
It assigns the blocks’ constituting that 
loop a loop number of one, indicating that 
they form the innermost loop, which is the 
first to undergo complete optimization. 
(BAKT records the value 1 in the loop 
number field of the statement number entry 
for each block in that loop.) BAKT flags 
the loop with the next highest depth number 
as the second loop to be processed. It 
assigns the blocks in that loop a loop 
number of two, indicating that they form 
the second (or next outermost) loop to be 
processed. (A value of 2 is recorded in 
the loop number field of the statement 
number entry for each block in that loop.) 
BAKT repeats this procedure until the loop 
with a depth number of one is processed. 
It then assigns the highest loop number to 
the blocks with a depth number of zero, 
indicating that they do not form a loop. 


If at any time, groups of blocks with 
the same depth number but different back 
targets are found, each group is ina 


different loop. Therefore, each such 100p 
is, in turn, processed before blocks having 
a lesser depth number are considered. 
Thus, if the blocks of two loops have the 
same depth number, BAKT assigns the blocks 
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of the first loop the next ioop number. It 
assigns the blocks of the second loop a 
loop number one greater than that assigned 
to the blocks of the first loop. 

When loop numbers are assigned to the 
blocks of ail moduie loops, the order in 
which the loops are to be processed has 
been specified. Control is passed to the 
routine that determines the busy-on-exit 
intormation and then to the loop' selection 
routine to select the first (innermost) 
loop to be cCperated upon. This loop' con- 
Sists of all blocks having a loop number of 
one. 


BUSY-ON-EXIT INFORMATION 


Before the module can be prccessed on a 
loop-by-loop basis, information indicating 
which variables are busy-on-exit from whicn 
text blocks must be gathered. A variable 
is busy immediately preceding a use of that 
variable, but is not busy immediately 
preceaing a definition of that variable. 
Thus, a variable is busy-on-exit from the 
blocks which are along ali paths connecting 
a use and a prior definition of that 
variable. This means that in subsequent 
blocks the variable can be used before it 
is defined. The busy-on-exit condition for 
a variable assures that its proper value 
exists in main storage or in a register 
along each path in which it is subsequently 
used. 


Information about the regions in which a 
variaple is busy or not busy determines 
whether or not a definition of that varia- 
ble can pe moved out of a loop. For 
example, if a variabie is busy-on-exit from 
the back target of a ioop, text optimiza- 


tion (see “Text Optimization") would not 
attempt to move to the back target a 
redefinition of that variable, because, if 


moved, the value of the variable, as it is 
processed aiong various paths from the back 
target, might not be the desired one. 
Conversely, if the variable is not busy-on- 
exit, the redefinition can be moved without 
affecting the desired value of the 
variable. Thus, text optimization respects 
the redefinitions of variables that are 
busy-on-exit from the back target of a 
loop. 


The information about regions in which a 
variable is busy or not busy also deter- 
mines whether or not loads and stores of a 
register assigned to the variable are 
required. For example, in full register 
assignment (see "Full Register Assignment 
During Complete Optimization"), variables 
that are assigned registers during global 
assignment and that are busy-on-exit from 
the back target of the loop must have an 
initializing load of the register placed 
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into the back target. The load is required 
because the variable may be used before its 
value is defined. Conversely, if the glob- 
ally assigned variable is not busy-on-exit 
from the back target, an initializing load 
is unnecessary. 


Phase 15 provides phase 20 with not 
busy-on-entry information for each operand 
that is assigned a coordinate (an MVD table 
entry). The not busy-on-entry information 
is recorded in the MVX field of the state- 
ment number text entry for each text block 
(see phase 15, "Gathering Constant/Variable 
Usage Information"). An operand is not 
busy-on-entry to a block, if in that block 
that operand is only defined or defined 
before it is used. Phase 20 converts the 
not busy-on-entry information to busy-on- 
entry information. An operand is busy-on- 
entry to a block, if in that block that 
operand is only used or used before it is 


defined. Finally, phase 20 converts’ the 
busy-on-entry information to busy-on-exit 
information. The backward connection 


information in CMAJOR is used to make the 


final conversion. 


The routine that performs the conver- 
sions is BIZxX. This routine determines 
busy-on-exit information for each constant, 
variable, and base variable having an asso- 
ciated MVD table entry or coordinate. How- 
ever, because constants and base variables 
are only used, they are busy-on-exit 
throughout the entire module. Therefore, 
the remainder of this discussion deals with 
the determination of busy-on-exit informa- 
tion for variables. 


Because RETURN statements (exit blocks) 
and references to subprograms not supplied 
by IBM constitute implicit uses of varia- 
bles in common, all common variables and 
arguments to such subprograms are first 
marked as busy-on-entry to exit blocks and 
blocks containing the references. The com- 
mon variables and arguments are found by 
examining the information table entries for 
all variables in the MVD table. The module 
is then searched for blocks that are exit 
blocks and that contain references to sub- 
programs not supplied by IBM. The _ coordi- 
nate bit for each previously mentioned 
variable is set on in the MVF field of the 
statement number text entry for each such 
block, while the same coordinate bit in the 


MVX field is set off. This defines the 
variable to be busy-on-entry to sucha 
block. During this process, a table, con- 


sisting of pointers to exit blocks, is 


built for subsequent use. 


After the blocks discussed above have 
been appropriately marked for common varia- 
bles and arguments, BI2ZX, working with the 
coordinate assigned to a variable, converts 
the not busy-on-entry information for the 
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variable to a table of pointers to blocks 
to which the variable is  busy-on-entry. 
(The not busy-on-entry information for the 
variable is contained in the MVX fields of 
the statement number text entries for the 
various text blocks.) At the same time, 
the variable's coordinate bit in each MVX 
field is set off. The busy-on-exit table 
and cCMAJOR are then used to set on the MVX 
coordinate bit in the statement number text 
entry for each block from which the varia- 


ble is busy-on-exit. This procedure is 
repeated until all variables have been 
processed. Control is then passed to the 


control routine of phase 20 (LPSEL). 


To convert not busy-on-entry information 
to busy-on-entry information, BIZX starts 
with the second MVD table entry, which 
contains a pointer to the variable assigned 
coordinate number two, and works down the 
chain of text blocks. The associated MVxX 
coordinate bit in the statement number text 


entry for each block is examined. If the 
coordinate bit is off, the corresponding 
MVF coordinate bit is inspected. If the 
MVF coordinate bit is on, a pointer to the 
associated text block is placed into the 
busy-on-entry table. This defines the 


variable to be busy-on-entry to the block 
(i.e., the variable is used in the block 
before it is defined). If the associated 
MVX coordinate bit is on, indicating that 
the variable is not busy-on-entry, BIZX 
sets the bit off and proceeds to the next 
block. This process is repeated until the 
last text biock has been processed. 


After BIZX has set off the MVX coordi- 
nate bit (associated with the variable 
under consideration) in each statement num- 
ber text entry and built a table of point- 
ers to blocks to which the variable is 
busy-on-entry, it determines the blocks 
from which the variable is busy-on-exit. 


Starting with the 
busy-on-entry table, 
CMAJOR) pointers to 
backward connections of that entry. Each 
backward connecting block is examined to 
determine whether or not it meets one of 
three criteria, which are: 


first entry in the 
BIZX obtains (from 
ali blocks that are 


e The block contains a definition of the 
variable (i.e., the variable's MVS 
coordinate bit is on). 


e The variable has already been marked as 
busy-on-exit from the block. 


¢ The block corresponds to the busy-on- 
entry table entry being processed. 


If the block meets one of these 
criteria, the variable is busy-on-exit from 
the block and its associated MVX coordinate 


bit is set on. (The backward connections 
of that block are not explored.) 


If the backward connecting block does 
not meet any one of these criteria, the 
variable is marked as _ busy-on-exit from 
that block and that block's backward con- 
nections are, in turn, explored. The same 
criteria are then applied to the backward 
connecting blocks. The backward connection 
paths are explored in this manner until a 
block in every path satisfies one of the 
criteria. 


If, during the examination of the back- 
ward connections, an entry block (i.e., a 
block lacking backward connections) is 
encountered, the blocks in the table of 
exit blocks, which was previously built by 
BIZX, are used as the backward connections 
for the entry block. Processing then con- 
tinues in the normal fashion. 


When blocks in all backward connecting 
paths have satisfied one of the criteria, 
BIZX obtains the next entry in the busy-on- 
entry table and repeats the process. This 
continues until the busy-on-entry table has 
been exhausted. 


When the busy-on-entry table has been 
exhausted, the procedure of building the 
busy-on-entry table and converting it to 
busy-on-exit information is repeated for 
the next MVD table entry. When alli MVD 
table entries have been processed, BIZX 
passes control to LPSEL, which calls the 
loop selection routines. 


STRUCTURED SOURCE PROGRAM LISTING 


If both the EDIT option and complete 
optimization are selected, after subroutine 


BIZX has compiled the busy-on-exit 
information, control is passed to _ subrou- 
tine SRPRIZ, which records on the SYSPRINT 


data set a structured source program list- 
ing. This listing indicates the loop 
structure and logical continuity of the 
source program. (A complete description of 
the structured source listing is given in 


the publication IBM System/360 Operating 
System: FORTRAN IV (H) Programmer's Guide.) 


To produce the listing, SRPRIZ reads the 
SYSUT1 data set prepared by phase 10 and 
associates, by means of statement numbers, 
the individual source statements with the 
text blocks formed from them. By analysis 
of the loop number information gathered for 
the text blocks, SRPRIZ then identifies the 
source statements that make up a particular 
loop and flags them on the listing by 
corresponding loop number. SRPRIZ aiso 
uses the previously gathered back dominator 
information to compute listing indentations 
for the statements. The indentations show 
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dominance relationships; that is, SRPSIZ 
indents the statements that form a text 
block from the statements that form the 
back dominator of that block. 


LOOP SELECTION 


The loop selection routines of phase 20 
(TARGET, BASVAR, and BSYONX) select the 
loop to be processed and provide the text 
optimization and full register assignment 
routines with the information required to 
process the loop. 


The loop to be processed is selected 
according to the value of a loop. number 
parameter, which is passed to the loop 
selection routines. The control routine of 
phase 20 (LPSEL) sets this parameter to one 
after the process of structural determina- 
tion is complete. The loop selection rou- 
tine TARGET is called to select the loop 
whose blocks have a corresponding loop 
number. The selected loop is then passed 
to the text optimization routines. When 
text optimization for the loop is complet- 
ed, the control routine increments’ the 
parameter by one, sets the loop number of 
the blocks in the loop just processed to 
that of their back target, and marks those 
biocks as completed. The control routine 
again calls TARGET, which selects the loop 
whose blocks correspond to the new value of 
the parameter. The selected loop is then 
passed to the text optimization routines. 
This process is repeated until the outer- 
most loop has been text-optimized. 


After text optimization has processed 
the entire module (i.e., the last loop), 
the control routine removes the block com- 
pletion marks, initializes the loop number 
parameter to 1, and passes control to 
TARGET to reselect the first loop. Control 
is then passed to the full register assign- 
ment routines. When full register assign- 
ment for the loop is completed, the control 
routine marks the blocks of the loop as 
completed. It then increments the parame- 
ter by 1 and passes control to TARGET to 
select the next loop. Full register 
assignment is then carried out on the loop. 
This process is repeated until the outer- 
most loop has undergone full register 
assignment. (When full register assignment 
has been carried out on the outermost loop, 
the control routine passes control to the 
routines that compute the size of each text 
block and then to the routine that computes 
the displacements reguired for branching 
optimization.) 


The loop selection routine TARGET uses 
the value of the loop number parameter as a 
basis for selecting the loop to be proc- 
essed. TARGET compares the loop number 
assigned to each text block to the parame- 
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ter. It marks each block having a loop 
number corresponding to the value of the 
parameter as an element of the loop to be 
processed. It does this by setting on a 
bit in the block status field of the 
statement number entry for the block (refer 
to Appendix A, “Statement Number/Array 
Table"). When all such blocks are marked, 
the loop has been selected. 


The information required by the text 
optimization and full register assignment 
routines to process the loop consists of 
the following: 

e A pointer to the back target of the 
loop. 


e A pointer to the forward target of the 
loop (if any). 

e Pointers to both the first and last 

blocks of the loop. 


® The loop composite matrixes. 
After the loop has been selected, this 
required information is gathered. 


Pointer to Back Target 


The text optimization and full register 
assignment routines place both relocated 
and generated text entries into the back 
target of the loop. Although the back 
target of the loop was previously identi- 
fied during structural determination, it 
was not saved. Therefore, its identity 
must be determined again. 


The loop selection routine TARGET deter- 
mines the back target of the loop by 
obtaining the first block of the selected 
loop. It then analyzes the blocks in the 
chain of back dominators of the first block 
to locate the nearest block in the chain 
that is outside the loop and that passed 
coztrol to only one block. That block is 


the back target of the loop, and TARGET 
saves a pointer to it for use in the 
subsequent processing of the loop. 
Pointer to Forward Target 

The text optimization and full register 


assignment routines place both relocated 
and generated text entries into the forward 
target of the loop. The forward target of 
a loop (if it exists) is the single block 
to which the loop passes control after its 
execution is complete. 


To locate the forward target (if any), 


the loop selection routine BSYONX analyzes 
the backward connection information (in 
CMAJOR) for each block that is not in the 


It marks all such blocks 
block 


selected loop. 
that receive control directly froma 
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in the selected loop as exit blocks. If 
only one exit block exists, that block is 
the forward target of the loop. (The 
forward target must not be entered from a 
block not in the loop.) BSYONX saves a 
pointer to the forward target for use in 
the subsequent processing of the loop. 


If the above condition is not met, the 
loop does not have a defined forward tar- 
get. 


Pointers to First and Last Blocks 


The pointers to the first and last 
blocks of the selected loop indicate to the 
text optimization and full register assign- 
ment routines where they are to initiate 
and terminate their processing. To make 
these pointers available, and loop. selec- 
tion routine TARGET merely determines the 
first and last blocks of the selected loop 
and saves pointers to them for use in the 
subsequent processing of the loop. TO 
determine the first and last blocks, TARGET 
searches the statement number chain for the 
first and last entries having the current 
loop number. The block associated with 
those entries are the first and last in the 
loop. 


Loop Composite Matrixes 


The loop composite matrixes, LMVS, LMVF, 
and LMVX, provide the text optimization and 
full register assignment routines with a 
summary of which operands are defined with- 
in the selected loop, which operands are 
used within that loop, and which operands 
are busy-on-exit from that loop. (An oper- 
and is busy-on-exit from the loop if it is 
used before it is defined in any path along 
which control flows from the loop.) 


The LMVS matrix indicates which operands 
are defined within the loop. The loop 
selection routine BASVAR forms LMVS_ by 
combining, via or OR operation, the indi- 
vidual MVS fields in the statement number 
text entry of every block in the selected 
loop. 


The LMVF matrix indicates which operands 
are used within the loop. BASVAR forms it 
by combining, via an OR operation, the 
individual MVF fields in the statement 
number text entry of every block in the 
selected loop. 


The LMVX matrix indicates which operands 
are busy-on-exit from the selected loop. 
BSYONX forms it during its search for the 
forward target of the loop. BSYONX exam- 
ines the text entries of each block that is 
not in the selected loop and that receives 
control froma block in that 1oop. Any 
operand in the text entries of such a block 
that is either only used in the block or 


used before it is defined is  busy-on-exit 
from the loop. BSYONX sets on the bit in 
the LMVX matrix that corresponds to the 
coordinate assigned to each such operand to 
reflect that it (i.e., the operand) is 
busy-on-exit from the loop. 


TEXT OPTIMIZATION 


The text optimization process of phase 
20 detects text entries within the loop 
under consideration that do not contribute 
to the loop's successful execution. These 
non-essential text entries are either com- 
pletely eliminated or are relocated to a 
block outside of the current loop. Because 
the most deeply-nested loops are presented 
for optimization first, the number of text 
entries in the most strategic sections of 
the object module will approach a minimum. 


The processing of text optimization is 
divided into four logical sections: common 
expression elimination, forward movement, 
backward movement, and strength reduction. 


* Common expression elimination optimizes 
the execution of a loop by eliminating 
unnecessary re-computations of identi- 
cal arithmetic expressions. 


© Forward movement optimizes the execu- 
tion of a loop by relocating to the 
forward target computations essential 
to the module but not essential to the 
current loop. 


e Backward movement optimizes the execu- 
tion of a loop by relocating to the 
back target computations essential to 
the module but not essential to the 
current loop. 


e Strength reduction optimizes the 
incrementation of DO indexes and the 
computation of subscripts within the 
current loop. Modification of the DO 
increment may allow multiplications to 
be relocated into the back target. If 
the DO increment is not busy-on-exit 
from the loop, it may be completely 
replaced by a new DO increment that 
becomes both a subscript value anda 
test vaiue at the bottom of the DO. 


The first three of the above sections 
are Similar in that they examine text 
entries in strict order of occurrence with- 
in the loop. 


The last section does not examine indi- 
vidual text entries within the loop; 
instead, the TYPES table, constructed prior 
to its execution, is consulted for optimi- 
zation possibilities. Furthermore, an 
interaction of entries in the TYPES table 
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must exist before processing can proceed. 
The TYPES table contains pointers to type 
3, 4, 5, 6, and 7 text entries. The 
various types, their definitions, and the 
section(s) of text optimization that proc- 
ess them are outlined in Table 3. Pointers 
to type 1 and type 2 text entries are not 


entered into the TYPES table. The reason 
is that such types have already been proc- 
essed during backward movement. (Although 


type 4 text entries are included in the 
table, they are not optimized by this 
version of the compiler.) 


The following text describes the proc- 
essing performed by each of the sections of 
the text optimization. An example illus- 
trating the type of processing of each 
section is given in Appendix D. These 
examples should be referred to when reading 
the text describing the processing of the 
sections. 


Common Expression Elimination 


The object of common expression elimina- 
tion, which is carried out by subroutine 
XPELIM, is to eliminate any unnecessary 
arithmetic expressions. This is accom- 
plished by eliminating text entries, one at 
a time, until the entire expression disap- 
pears. An arithmetic text entry is unnec- 
essary if it represents a value (calculated 
elsewhere in the loop) that may be used 
without modification. A value may be used. 
without modification if, between appearan- 
ces of the same computation, Operands 2 and 
3 of the text entry are not redefined. The 
following paragraphs discuss the processing 
that occurs during common expression elimi- 
nation. 


Within the current loop, XPELIM examines 
each uncompleted biock (i.e., a block that 
is not part of an inner loop) for text 
entries that are candidates for elimina- 
tion. A text entry is a candidate if it 
contains an arithmetic, logical, or sub- 
Script operator. Once a candidate is 
found, XPELIM attempts to locate a matching 
text entry. A text entry matches the 
candidate if operand 2, operand 3, and the 
operator of that text entry are identical 
to those of the candidate. If either 
operand 2 or 3 of the matching text entry 
is redefined between that text entry and 
the candidate, the match is not accepted. 
The search for the matching text entry 
takes place in the following locations: 


e In the same 
between the 
candidate. 


block as the candidate, 
first text entry and the 


e In a back dominator (see note) of the 
block in which the candidate resides. 
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Table 3. Text Entry Types 


aso eta a Ea a ae ae ee See ae ee Tt Re te eg et eee ay ee a ay 
| TYPE | DEFINITION | PROCESSED BY | 
}-------- }-------~-~----------------------------------- }-----~~-----~---~---~----------- { 
| Type 1 | A text entry having an absolute constantt | | 
| | in either the operand 2 or operand 3 {| Backward Movement 
| | position. | | 
}-------- }-~---~~----------------------=--------------- }-~---~--~------~----~----------- { 
| Type 2 | A text entry having stored constants? in | Backward Movement | 
| | both the operand 2 and operand 3 positions. | j 
}-------- |-+--=-~-------~---------- = ------------------------------=- { 
| Type 3 | An inert text entry (i.e., a text entry | | 
| | that is a function of itself and an addi- | Strength Reduction | 
| | tive constant; e.g., J=J+1) | | 
}------~- |--~---~-------------------------------------- f------------------=------------- { 
| Type 4 | A subscript text entry | 
}------—- : SaE-TnDP aud ge getup tenep Une a> tnda RERERGERIGUEE f----------------- += == $= === { 
| Type 5 | A text entry whose operand 1 (a temporary) | | 
| | is a function of a variable (or temporary) | Strength Reduction i 
| | and a constant, and whose operator is | | 
| | multiplicative (*, /, or ¥). | | 
}-~~--~—— ee eae Reap ae NO a lg Aro SR ea fon a nanan one { 
| Type 6 | A text entry whose operand 1 (a temporary) | | 
| | is a function of a variabie (or temporary) | Strength Reduction | 
| J and a constant, and whose operator is | | 
| | additive (+, -, or <). | | 
}----~--~ fran nanan nn nnn {-—-~--~-—-~—-~--~~--~--~-------- { 
| Type 7 | A branch text entry | Strength Reduction 
Soe eeS Mesa So ee ee eo kee ee Me So at ae 


{tAbsolute constants are those that agree with the definition of numerical constants as 
| stated in the publication IBM System/360 Operating System: FORTRAN IV. 


|2A stored constant is a variable that is not defined within a loop, and thus its value 
| remains constant throughout execution of that loop. 


Note: Only back dominators that are not 
elements of previously processed loops and 
that are within the confines of the current 
loop are considered. The first back domi- 
nator considered is the one nearest to the 
block being processed. The next considered 
is the back dominator of the nearest back 
dominator, etc. 


When a matching text entry is found, 
XPELIM performs elimination in the follow- 
ing way: 


e If operand 1 of the matching text entry 
is not redefined between that text 
entry and the candidate, XPELIM substi- 
tutes that operand for operand 2 of the 
candidate and converts the operator to 


a store. 
e If, on the other hand, operand i is 
redefined, XPELIM generates a text 


entry to save the value of operand 1 in 
a temporary and inserts this text entry 
into text immediately after the match- 
ing text entry. It then replaces oper- 
and 2 of the candidate with this tem- 
porary, and converts the operator to a 
store. 
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e Finally, if operand 1 of the candidate 
is a temporary generated by phase 15, 
XPELIM replaces all uses of the tem- 
porary with the new operand 2 of the 
candidate and deletes the candidate. 
Thus, the value of the matching text 
entry is propagated forward for possi- 
ble participation in another candidate. 
This provides the link to the next text 
item of the complete common expression. 


in the block under 
consideration are processed in the pre- 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop is selected and its text 
entries undergo common expression elimina- 
tion. When all uncompleted blocks in the 
loop are processed, control is returned to 
the control routine of phase 20, which 
passes control to the portion of phase 20 
that continues text optimization through 
forward movement. 


All text entries 


The overall iogic of common expression 
elimination is illustrated in Chart 11. An 
example of common expression elimination is 
given in Appendix D. 


Forward Movement 


Forward movement, which is carried out 
by subroutine FORMOV, optimizes a loop by 
moving text entries from the loop to the 
forward target of the loop, an area where 
they are executed less often. If the loop 
does not have a defined forward target, 
forward movement is bypassed and backward 
movement is initiated. Only text entries 
that are not required in the loop are moved 
during forward movement. An example of 
such a text entry is one whose operand 1 is 
not needed elsewhere in the loop. The 
following paragraphs describe the process- 
ing that occurs during forward movement. 


Within the loop currently being opti- 
mized, FORMOV examines each uncompleted 
block in the chain of back dominators of 


the forward target (starting with the near- 
est back dominator of the forward target 
and proceeding as described in common 
expression elimination) for text entries 
that are candidates for forward movement. 
(The block is examined in a bottom-to-top 
fashion.) A text entry is a candidate for 
forward movement if: . 


e The text entry contains an arithmetic 
or logical operator. 


e Operand 1 of the text entry is not used 
in another text entry in the loop. 


When a candidate is found, FORMOV per- 
forms forward movement of the candidate in 
one of two ways: 


e If the operands of the candidate are 
not defined in the text entries between 
candidate and the forward target, FOR- 
MOV moves the entire candidate to the 
beginning of the forward target. 


e If an operand of the candidate is 
defined and if the expression (i.e., 
operand 2-operator-operand 3) in the 


candidate contains a variable and tem- 
porary, joined by a commutative opera- 
tor, FORMOV generates a text entry to 
Store the variable in a new temporary. 
It then replaces the candidate with 
this text entry, moves the candidate to 
the forward target, and replaces the 
variable with a reference to the new 
temporary. 


All the text entries in the block under 
consideration are processed in the pre- 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop that is also a back 
dominator of the forward target is selected 
and its text entries undergo forward move- 
ment. When all uncompleted blocks that are 
back dominators of the forward target and 
within the confines of the loop are proc- 
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essed, control is returned to the control 
routine of phase 20, which passes control 
to the portion of phase 20 that continues 
text optimization through backward move- 
ment. 


The overall logic of forward movement is 
illustrated in Chart 12. An example of 
forward movement is given in Appendix D. 


Backward Movement 


Backward movement, which is performed by 
subroutine BACMOV, moves text entries from 
a loop to an area that is executed less 
often, the back target of the loop. During 
backward movement, each uncompleted block 
in the loop being processed is examined for 
text entries that are candidates for back- 
ward movement. To be a candidate for 
backward movement, a text entry must: 


e Contain an arithmetic or logical opera- 
tor. 

e Have operands 2 and 3 that are not 

defined within the loop. 


When a candidate is found, BACMOV car- 
ries out backward movement of that candi- 
date in one of two ways: 


e If operand 1 of the candidate is not 
busy-on-exit from the back target of 


the loop and if operand 1 of the 
candidate is not defined elsewhere in 
the loop, BACMOV moves the entire can- 


didate to the back target of the loop. 
(An operand is not busy-on-exit from 
the back target if that operand is 
definea in the loop before it is used.) 


e If operand 1 of the candidate is busy- 
on-exit from the back target of the 
loop or if it is defined elsewhere in 
the loop, BACMOV generates a text entry 
to perform the computation of the 
expression in the candidate and store 
the result in a new temporary. It 
moves this text entry to the end of the 
back target of the loop and then repla- 
ces the expression in the candidate 
with operand 1, the new temporary, of 
the generated text entry. 


All the text entries in the block under 
consideration are processed in the pre- 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop is selected and its text 
entries undergo backward movement. When 
all uncompleted blocks in the loop are 
processed, control is returned to the con- 
trol routine of phase 20, which passes 
control to the portion of phase 20 that 
continues text optimization through 
strength reduction. 
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The overall logic of backward movement 
is illustrated in Chart 13. An example of 
backward movement is given in Appendix D. 


Two additional optimization processes 
are performed concurrently with backward 
movement. They are the elimination of 
Simple stores and of arithmetic expressions 
that appear in text entries and are func- 
tions of integer constants. 


Elimination of Simple Stores: BACMOV 
removes unnecessary Simple stores (i.e., 
text entries of the form “operand 1 = 


operand 2") from the block that is current- 
ly undergoing backward movement. The fol- 
lowing paragraphs describe the processing 
that occurs during simple-store elimina- 
tion. 


During the scan of each uncompleted 
block for text entries to be moved to the 
back target, BACMOV checks’ for simple 
stores that are candidates for elimination. 
A simple store is a candidate for elimina- 
tion if its operand 1 is a variable. 


When a candidate is found, BACMOV exam- 
ines the characteristics of its operands to 
determine if the candidate can be eliminat- 
ed. The various combinations of operand 
characteristics that permit a candidate to 
be eliminated are given in Table 4. If the 


characteristics of the operands of the 
candidate conform to any one of these ten 
combinations, BACMOV eliminates the candi- 
date. 


It does this by replacing the uses of 
operand 1 (of the candidate to be 
eliminated) with operand 2 of the candidate 
in text entries between either: 


e The candidate and the first redefini- 
tion of either operand. 


e The candidate and the end of the 
(i-.e., if a redefinition of 
operand does not occur). 


block 
either 


candidate. An 
elimination is 


BACMOV then deletes’ the 
example of simple-store 
illustrated in Appendix D. 


Elimination of Text Entry Expressions 


Involving Integer Constants: During the 
scan Of a block for text entries to be 


moved to the back target, BACMOV also 
checks for text entries whose operators are 
arithmetic and whose operands 2 and 3 are 
both integer constants. When such a text 
entry is found, BACMOV eliminates the 
arithmetic expression in the text entry by: 


® Caiculating the resuit of the 
sion. 


expres- 


Table 4. en Characteristics That Permit eas eae Elimination 
lopecana 1 loperand 4 jOpevana > operand 1 geca operand uf Pes operana 1 redefined be-| 
jbusy-on-exit |refined |redefinedjin block below|defined below|low between redefini- | 
|from block {below in |below in |redefinition |before redef-|tion of operand 2 and | 
| | block | block jof operand 2 |inition of |first use of operand 1 | 
| | | | JOperand 2 Jthat follows redefini- | 
| | | | | jtion of operand 2 | 
}-------------- }~-------- f-—------- }------------~- }------------- }----------------------- : 
J1. No | No | No | xX | X | X | 
}--~----~------~ $--------- ----~---~ $-------------- ~---~----~--- }~--------------~------- { 
[pee No | Yes | No | X | X | Xx | 
}----~--------- }~-------- }--------- }-------------- $------------- }~-----------------~---- : 
|3. Yes | Yes | No | xX | X | xX 
~------------- $----~----}---------f ------ =f ff 
}4. No | No | Yes | No | X | X 
[-------------- $-------~- $--------- {-------------- $----~-------- }~---------------------- : 
[5. No | Yes | Yes | No | Z | X 
}-------------- }-~------- }----———- }-------------- }---------—--- }----------------------- { 
}6. No | Yes | Yes | Yes | Yes | X 
--~----------- }---------}---------}-------------- f= -- $= ff 
bits No | Yes | Yes | Yes | No | Yes | 
[---~---------- }+--------- $-------~- }-------------- $------------- }----------------------- : 
{8. Yes | Yes | Yes | No | Z | xX 
}-------------- f-~------- 4--------- }-------------- }~------------ }----------------------- { 
[9. yes | Yes | Yes | Yes | Yes | X | 
~~----~------- fa-- nn -- = == fn nnn nf nn nnd 
{10. Yes | Yes | Yes | Yes | No | Yes | 
}------~----__- HS eapre eee ear ee fee eon hove sesa soos oS be sa Se eS i asti e atie ee eed 4 
|X = condition cannot exist because of previous characteristics of operands. | 
|Z = characteristic is irrelevant. | 


e Creating a new dictionary entry for the 
result, which is a constant. 

e Replacing the arithmetic 

with the result. 


expression 


The text entry is thereby reduced toa 
Simple store, which may be eliminated by 
simple-store elimination. 


Strength Reduction 


Strength reduction, which is performed 
by subroutine REDUCE, Optimizes loops that 
are controlled by iogical IF statements. 
(DO loops are converted to loops controlled 
by logical IF statements during Phase 10 
processing.) Such loops are optimized by 
modifying the expression (e.g., J<20) in 
the IF statement; this enables certain text 
entries to be moved from the loop to the 
back target of the loop, an area of lower 
frequency of execution. The processing of 
strength reduction is divided into two 
sections: 


e Elimination of multiplicative text. 
e Elimination of additive text. 


Both of these sections perform strength 
reduction, but each has a separate set of 
criteria for considering a loop as a candi- 
date for reduction. However, the manners 
in which these sections implement reduction 
are essentially the same. 


Elimination of Multiplicative Text: To 
eliminate multiplicative text, REDUCE exam- 


ines the loop being processed to determine 
if it is a candidate for strength reduc- 
tion. The loop is a candidate if: 


e The loop contains an inert text entry 
(a type 3 text entry). 


e Operand 1 of the inert text 
used in another text entry (in the 
loop) whose operator indicates multi- 
plication and whose other used operand 
is a constant1 (a type 5 entry). 


entry is 


e Operand 1 of the inert text entry is 
the variable appearing in the expres- 
sion of the logic IF statement that 
controls the loop. 


If the loop is a candidate, REDUCE 
implements strength reduction in one of two 
ways: 


1. If the constants in the inert text 
entry and the multiplicative text 
entry are both absolute constants, 
REDUCE: 


1This other text entry is referred to as a 
multiplicative text entry. 
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a. Calculates a new constant (K) 
equal to the product of the abso- 
lute constants. 


b. Generates another inert text entry 


and inserts it into the loop 
immediately after the original 
inert text entry. The additive 


constant in this text entry is kK. 


c. Modifies the 
logical IF by: 


expression in the 


1. Replacing the branch variable 
(see note) with operand 1 of 
the generated inert text 
entry. 


2. Replacing the branch constant 
(see note) with a constant 
equal to the product of the 
branch constant and K. 


d. Deletes the original inert text 
entry if operand 1 of that text 
entry is not busy-on-exit from the 
loop. 


e. Moves the multiplicative text 
entry to the back target of the 
loop. 


f. Replaces operand 1 of the multi- 


plicative text entry with operand 
1 of the generated inert text 
entry. 


g- Replaces the uses of operand 1 of 
the multiplicative text entry that 
remain in the loop with operand 1 
of the generated inert text entry. 


Note: The branch variable is the 
variable in the expression of the 
logical IF that is tested to 
determine if the loop is to be 
reexecuted. The branch constant 
is the constant to which the 
branch variable is compared. For 
example, IF (J<3) where J is the 
branch variable and 3 is the 
branch constant. 


If either of the constants in the 
inert text entry or the multiplicative 
text entry is a stored constant, 
REDUCE performs Similar processing to 
that described above. However, prior 
to generating the inert text entry, it 
generates two additional text entries 
and piaces them into the back target 
of the loop. The first text entry 
multiplies the two constants. Operand 
1 of this text entry becomes the 
additive constant in the generated 
inert text entry. The second text 
entry multiplies operand 1 of the 
first generated text entry by the 
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branch constant. Operand 1 of the 
second text entry becomes the new 
branch constant of the logical IF. 


If additional multiplicative text 
entries exist within the loop, the above 
process is repeated. Repetitive processing 
of this type results in a number of gener- 
ated inert text entries, which may be 
eliminated from the loop by the processing 
of the second section of strength reduc- 
tion. 


Elimination of Additive Text: To eliminate 
additive text, REDUCE examines the loop 
being processed to determine if it is a 
candidate for strength reduction. The loop 
is a candidate if: 


¢ The loop contains an inert text entry 
(type 3). 


e Operand 1 of the inert text entry is 


used in the loop in another text entry 
whose operator indicates addition? 
(type 6). 


If the loop is a candidate, the process- 
ing performed by REDUCE to eliminate the 
additive text entry is essentially the same 
as that performed to eliminate a multi- 
plicative text entry. 


The overall logic of strength reduction 
is illustrated in Chart 14. An example 
showing both methods of strength reduction 
is given in Appendix D. 


FULL REGISTER ASSIGNMENT DURING COMPLETE 
OPTIMIZATION 


During complete optimization, full reg- 
ister assignment is carried out on module 
loops, rather than on the entire module, as 
is the case for intermediate optimization. 
Regardless of whether a loop or the entire 
module is being processed, the full reg- 
ister assignment routines operate essen- 
tially in the same manner. However, the 
optimization effect of full register 
assignment, when carried out on a loop-by- 
loop basis, iS more pronounced. Because 
the most deeply-nested loops are presented 
for full register assignment first, the 
number of register loads in the most 
Strategic sections of the object module 
will approach a minimum. The processing of 
a loop by full register assignment differs 
from its processing of the entire module 
only in the area of global assignment. An 
understanding of the processing performed 
on a loop, other than global assignment, 
can be derived from the previous discussion 


1This text entry is 
additive text entry. 


referred to as an 
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of full register assignment (refer to "Full 
Register Assignment"). Global assignment 
for a loop is described in the following 
text. 


When processing a loop, 
assignment routine (GLOBAS) incorporates 
into the current loop, wherever possible, 
the global assignments made to items (i.e., 
operands and base addresses) in previously 
processed loops. It does this to ensure 
that the same register is assigned in both 
loops if an item eligible for global 
assignment in the current loop was globally 
assigned in a previously processed loop. 


the global 


Before the global assignment routine 
assigns an available register to the most 
active item of the current loop, it deter- 
mines whether that item was globally 
assigned in a previously processed loop. 
(As global assignment iS carried out on 
each loop, all global assignments for that 


loop are recorded and saved for use when 
the next loop is considered.) If the item 
was not globally assigned in a previously 


processed loop, GLOBAS assigns it the first 


available register. If the item was glob- 
ally assigned in a previously processed 
loop, the giobal assignment routine then 


determines whether the register assigned to 
the item in the previously processed loop 
is currently available. If that register 
is available, GLOBAS also globally assigns 
it to the same item in the current loop. 
If the register is not available, the 
global assignment of that item in the 
previously processed loop cannot be incor- 
porated into the current loop. GLOBAS 
therefore assigns the item an available 
register different from that assigned to it 
in the previously processed loop. GLOBAS 
selects the eligible item with the next 
highest activity in the current loop and 
treats it in the same manner. Processing 
continues in this fashion until the supply 
of eligible items or the supply of availa- 
ble registers is exhausted. 


As each global assignment is made to an 
active item, GLOBAS checks to determine 
whether or not that item is busy-on-exit 
from the back target of the loop. If the 
item is busy-on-exit, GLOBAS generates a 
text entry to load that item into the 
assigned register and inserts it into the 
back target of the 10op. The load is 
required to guarantee that the item is ina 
register and available for subsequent use 
during loop execution. If the item is 
not-busy-on-exit, the load text item is not 
required. If any globally assigned item is 
defined within the loop and is also busy- 
on-exit from the loop, GLOBAS generates a 
text entry to store that item on exit from 
the loop. The generated store is needed to 
preserve the value of such an operand for 


use when it is required the 


execution of an outer loop. 


during 


GLOBAS records all global assignments 
made for the current loop for use in the 
subsequent updating scan (see "Full Reg- 
ister Assignment") and also for incorpora- 
tion, wherever possible, into subsequently 


processed loops. 


BRANCHING OPTIMIZATION DURING COMPLETE 
OPTIMIZATION 


During complete optimization, branching 
optimization is carried out in the same 
manner as during intermediate optimization. 
After all loops have undergone full reg- 
ister assignment, BLS is given control to 
calculate the size of each block. When the 
sizes of all blocks have been calculated, 
subroutine LYT uses the block size informa- 
tion to determine the blocks that can be 
branched to py means of RX-format branch 
instructions. 


PHASE 25 


Phase 25 produces an object module from 
the compined output of the preceding phases 
of the compiler. An object module consists 
of four elements: 


Text information. 

External symbol dictionary. 
Relocation dictionary. 
Loader END record. 


The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language form. It 
may contain unresolved external symbolic 
cross references (i.e., references to sym- 
bols that do not appear in the object 
module). The external symbol dictionary 
contains the information needed to resolve 
the external symbolic cross references 
appearing in the text information. The 
relocation dictionary contains the informa- 
tion needed to relocate the text informa- 
tion for execution. The END record informs 
the linkage editor of the length of the 
object module and the address of its main 
entry point. 


An object module resulting from a compi- 
lation consists of a single control sec- 
tion, unless common blocks are associated 
with the module. An additional control 
section is included in the module for each 
common block. 


The object module produced by Phase 25 
is recorded on the SYSLIN data set if the 
LOAD option is specified by the FORTRAN 
programmer, and on the SYSPUNCH data set if 
the DECK option is specified. If the LIST 
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option is specified, Phase 25 develops and 
records on the SYSPRINT data set an assemn- 
bler language listing of the instructions 
and data of the object module. Error 
messages produced during phase 25 (if any) 
are also recoraed on the SYSPRINT Gata set. 


TEXT INFORMATION 


Text information consists of the machine 
language instructions and data resulting 
from the compilation. Each text informa- 
tion entry (a TXT record) constructed by 
phase 25 can contain up to 56 bytes of 
instructions and data, the address of the 
instructions and data relative to the 
beginning of the control section, and an 
indication of the control section that 
contains them. A more detailed discussion 
of the use and format of TXT records is 
given in the publication IBM System/360 


Operating System: Linkage Editor, Program 
Logic Manual. 


The major portion of phase 25 processing 
is concernea with text information con- 
struction. In building text information, 
phase 25 optains each item that is to be 
placed into text information, converts the 
item to machine language form wherever 
necessary, enters the item into a TXT 
record, and places the relative address of 
the item into the TXT record. 


Phase 25 assigns relative addresses by 
means Of a jocation counter, which is 
continually updated to reflect the location 
at which the next item is to be placed into 
text information. Whenever phase 25 begins 
the construction of a new TXT record, it 
inserts the current value of the location 


counter into the address fieid of the TXT 
record. The address field of the TXT 
record thereby indicates the relative 


address of the instructions and data that 
are placed into the record. 


Figure 11 shows the 
that Phase 25 
information. 


layout of storage 
assumes in setting up text 


Phase 25 constructs text information by: 


e Reserving adcon table entries for the 
referenced statement numbers of the 
module. 

e Entering the constants of the 


source 
module into TXT records. ‘ 


® Reserving storage within text informa- 


tion for the variables and arrays of 
the module. 
e Translating FORMAT statements (i.e., 


phase 10 format text) to a form recog- 
nizable by IHCFCOMH and entering the 
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translated statements into TXT records. 
(IHCFCOMH, a member of the operating 
system library (SYS1.FORTLIB), performs 
object-time implementation of I/O 
statements. IHCFCOMH is explained in 
Appendix E.) 


Converting NAMELIST statements (i.e., 
phase 10 namelist text) to object-time 
namelist dictionaries, which are used 
by IHCFCOMH to implement READ-WRITE 
Statements using NAMELIST statements. 


Generating the main program or 
gram initialization instructions 
entering them into TXT records. 


subpro- 
and 


Completing the processing of the adcon 
table entries and entering the resul- 
tant entries into TXT records. 


Assigning the initial values, as 
fied, to the variables and 
appearing in phase 15 data text. 


speci- 
arrays 


Generating the 
instructions 
entering these 
records. 


prologue and epilogue 
for a subprogram and 
instructions into TXT 


Converting phase 15/20 standard text 
into System/360 machine code and enter- 
ing the code into TXT records. 


Address 
Registers 


12 ———_> 
Constants 





Variable and Arrays 





Translated FORMAT statements 
and object-time name list 
dictionaries 





subprogram main 
entry point 


Initialization Instructions 


| For main program or 
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Mation Construction 
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the statements associated with such 


Chart 21 shows the logic of phase 25 
processing, down to, but not including, 
conversion of text to machine code. 


Adcon Table Entry Reservation 


Prior to beginning its construction of 
text information, subroutine LYT1 reserves 
address constants for the referenced state- 
ment numbers of the module and for the 
statement numbers appearing in computed GO 
TO statements. The address constantS are 
reserved so that the relative addresses of 
state- 


ment numbers can be recorded, and subse- 
quently obtained during execution of the 
object module, when branches to those 


statements are required. 


To reserve address constants for state- 
ment numbers, subroutine LYTi scans the 
chain of statement number entries in the 
Statement number/array table. For eéach 
encountered statement number that is ref- 
erenced, LYT1 inserts into the appropriate 
field of the associated statement number 
entry a pointer to the next available entry 
in the adcon table. The actual value to be 
placed into the address constant set aside 
for a statement number is determined during 
text conversion (a subsequent phase 25 
process), when the text representation of 
that statement number is encountered. 

Note: If branching optimization is being 
implemented, LYT1 only reserves address 
constants for statement numbers that are 
associated with text blocks that can not be 


branched to via RX-format branch instruc- 
tions. 

After all statement numbers are proc- 
essed, address constants are likewise re- 


served for the statement numbers appearing 
in computed GO TO statements. LYT1 scans 
the branch table chain (refer to Appendix 
A, “Branch Table"), and sets aside an entry 
in the ADCON table for each statement 
number for which a branch table entry was 
constructed. It aiso records a pointer to 
the address constant reserved for each fall 
through statement number in the initial 
branch table entry for that statement num- 
ber. LYT1 does not record pointers to the 
address constants set aside for the actual 
Statement numbers of the computed GO TO 
Statements in their associated standard 
branch table entries. The values to be 
placed into the address constants for 
Statement numbers in computed GO TO state- 
ments are also determined during text con- 
version. 


Constant Processing 


Subroutine INITIL obtains the constants 
of the source module from their information 
table entries and places them into text 


-information via TXT records. The address 
field of each such record specifies rela- 
tive addresses for the constants that cor- 
respond to the relative addresses assigned 
‘to them by CORAL in Phase 15. 


Variable and Array Processing 


Subroutine INITIL reserves storage with- 
in text information for the variables and 
arrays of the moduie between the last 
constant and the first translated FORMAT 
statement, or the first object-time name- 


list dictionary, if FORMAT statements do 
not exist in the module. To accomplish 
this, INITIL assigns to the first trans- 


lated FORMAT statement (or object-time 
namelist dictionary) e relative address 
equal to the number of bytes occupied by 
the constants, variables, and arrays of the 
module. 


FORMAT Statement Processing 


If the source module contains READ/WRITE 
statements requiring FORMAT statements, the 
associate phase 10 format text must be put 
into a form recognizable by IHCFCOMH. Sub- 
routine FORMAT develops the necessary form 
by obtaining the phase 10 intermediate text 
representation of each FORMAT statement, 
and translating each element (e.g., H for- 
mat code and field count) of the statement 
according to Table 5. FORMAT enters the 


inserts the relative address of the trans- 
lated statement into the address constant 
for the statement number associated with 


the FORMAT statement. 
NAMELIST Statement Processing 


If the source module contains READ/WRITE 
Statements using NAMELIST statements, sub- 
routine NLIST converts phase 10 namelist 
text to object-time namelist dictionaries. 
The object-time namelist dictionaries pro- 
vide IHCFCOMH with the information required 
to implement READ/WRITE statements using 


namelists (refer to Appendix A, "Namelist 
Dictionaries"). The dictionary developed 
for each list in a NAMELIST statement 


contains the following: 
e An entry for the namelist name. 


e Entries for the variables and arrays 
associated with the namelist name. 


e An end mark of 
list. 


zeros terminating the 


Each entry for a variable contains the 
name, mode (e.g., integer*2 or real*4), and 
relative address of the variable. Both the 
address and the mode are obtained from the 
dictionary entry for the variable. 

Each 


entry for an array contains the 


translated statement along with its’ rela- name of the array, the mode of its ele- 
tive address into TXT records. It aiso ments, the relative address of its first 
Table 5. FORMAT Statement Translation 

ye a re ee i a aaa ak eR a SS RS No Ack CES CN 

| | Translated Form (in hexadecimal) | 
i FORMAT ee qooo + 

| Specification | Description | ist byte | 2nd byte | 3rd byte | 
}------------------- }---------------------------- j-—--------- {------------ }------------ { 
| | beginning of statement | 02 | | | 
| n ( | group count | O04 i n | | 
| n | field count | 06 | n | | 
| nP | scaling factor | 08 | n* { i 
| Fw.d | F-conversion | 0A | w | da | 
| Ew.d | E-conversion | OC | Ww | d i 
| Dw.d | D-conversion | OE | Ww | da | 
| Iw | I-conversion | 10 | Ww | | 
| Tn | column set | 12 | n | | 
| Aw | A-conversion | 14 | Ww | | 
| Lw | L-conversion | 16 | w | | 
| nx | skip or blank | 18 | n | | 
| nitext | | | | | 
| or j literal data | 1A | n | text | 
| "text! | | | | | 
| ) | group end | ic | | | 
| / | record end | 1E | | j 
| Gw.d | G-conversion | 20 | w | da | 
| | end of statement | 22 | | i 
| Zw | Hexadecimal conversion | 24 | w | | 
bee eee eee 1 espera Rie RN san real aE es ee arses Sats Ee one ee ae bea ee eager oe er ae 4 


1 if negative). 
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j*The first hexadecimal bit of the byte indicates the scale factor sign (0 if positive, | 


| The next seven bits contain the scale factor magnitude. | 
he ea pe ea we ang ee ot ect ala 
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element, and the information needed to 
locate a particular element of the array. 
NLIST obtains the above information, 


excluding the array name, from the informa- 


tion table. 


NLIST places the entries of the namelist 
dictionary along with their relative 
addresses into TXT records. It also places 
the relative address of the beginning of 
the namelist dictionary into the address 
constant for the namelist name. 


Initialization Instructions 


Phase 25 generates the machine instruc- 
tions for entry into a main program, a 
subprogram, or a subprogram secondary entry 
point. These instructions are referred to 
as initialization instructions and are 
divided into three catagories: 

e Main program entry coding, which is 
generated by subroutine ATTACH. 


e Subprogram main entry coding, which is 
generated by subroutine SUBR. 


e Subprogram secondary entry coding, 

which is generated by subroutine ENTRY. 

Once generated, these instructions are 
entered into TXT records. 


Main Program Entry Coding: The initializa- 
tion instructions generated by subroutine 
ATTACH for a main program perform the 
following functions: 


e Save the contents of general registers 
14 through 12. 


e Load the reserved registers with their 
associated addresses. (The address 
loaded into register 13 is that of the 
Save area. The address loaded into 
register 11, if reserved, is that of 
the save area plus 4096 bytes. The 
address loaded into register 10, if 
reserved, is that of the save area plus 
8192 bytes. The address loaded into 
register 9, if reserved, is that of the 
save area plus 12288 bytes.) 


e Load the address of the main program 
save area into register 4, and _ store 
register 4 into the save area of the 
calling program. 


e Save register 13 in the new save area. 


e Load register 15 with the address of 


IHCFCOMH. 


e Branch and link to subroutine IBFINT 
(arithmetic interruption subroutine of 
IHCFCOMH) so that it can set the inter- 
ruption mask. 
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® Load register 13 from register 4. 
e Branch to apparent entry point. 


e Load register 15 with the address of 


THCFCOMH. 


e Branch and link to STOP entry point in 
ITHCFCOMH. 


e Constant for STOP 0. 
e Set up a save area tnat receives the 
contents of the main program registers, 


if a subprogram is called. 


e Set up the address constants to be 
loaded into the reservec registers. 


Note: At execution time, subroutine IBFINT 
is given control to set the interruption 
mask. 


Subprogram Main Entry Coding: The initial- 


ization instructions generated by subrou- 
tine SUBR for the main entry point into a 
suoprogram perform the following functions: 


e Save the contents of general registers 
14 through 12. 


e Load the addresses of the prologue and 
epilogue of the subprogram into reg- 
isters. (For an explanation of pro- 
logue and epilcgue, refer to "Prologue 
and Epilogue Generation."™) 


e Load the reserved registers with their 
associated addresses. 


e Load the address of the save area of 
the subprogram into register 13. 


e Save the address of the save area of 
the calling routine and the address of 
the epilogue of the subprogram in the 
Save area of the subprogram. 


e Branch to the prologue. 


e Set up aesave area in which the con- 
tents of the registers used by the 


subprogram are saved, should that sub- 
program, in turn, call another  subpro- 
gram. 

e Set up address constants in which the 


addresses of the prologue and epilogue 
of the subprogram and the addresses to 
be placed into the reserved registers 
are inserted. 


Subprogram Secondary Entry Coding: The 


initialization instructions for a _ subpro- 
gram secondary entry point are essentially 
the same as those required for the main 
entry point. For this reason, phase 25 
makes use of a number of the initialization 


instructions for the main entry point in 
processing secondary entry points. 


Main entry point initialization instruc- 
tions that precede and include the instruc- 
tion that loads the prologue and epilogue 
addresses cannot be used, because each 
secondary entry point has its own associat- 
ed prologue and epilogue. Therefore, for 
secondary entry points, subroutine ENTRY 
generates initialization instructions that 
perform the following functions: 


e Save the contents of general 
14 through 12. 


registers 


® Load the addresses of the prologue and 
epilogue of the secondary entry point 
into registers. 


e Branch to the subprogram main entry 
point initialization instruction that 
loads the reserved registers with their 
associated addresses. 


e Set up address constants in which the 
addresses of the prologue and epilogue 


of the secondary entry point are 
placed. 

Subprogram secondary entry coding does 
not occupy storage within the 
"Initialization Instructions" section of 
text information (see Figure 11). That 
section is reserved for: 

e Main program entry coding, if the 
source module being compiled is a main 


program. 


e Subprogram main entry coding, if a 
subprogram is being compiled. 


The initialization instructions for sec- 
ondary entry points are generated by sub- 
routine ENTRY when the text representation 
of an ENTRY statement is encountered during 
the processing of intermediate text. . These 
instructions reside in the "Instructions" 
section of text information. 


Adcon Table Processing 


Entries in the compile-time adcon table 
consist of the true address constants (base 
addresses) assigned by CORAL for local 
constants and variables and for common 
variables, pointers to information table 
entries for arguments and external ref- 
erence address constants, temporaries and 
constants generated by phase 20, and re- 
served address constants, which are _ set 
aside for statement numbers. The output 
that the phase 25 subroutine NADOUT gener- 
ates for the object-time adcon table con- 
sists of TXT records and RLD records in the 
case of true address constants. The RLD 
records provide the information needed to 
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relocate the true address constants. (A 
type 5 ESD is output for each common 
block.) For argument address constants, 
NADOUT obtains the relative addresses of 


the arguments from their information table 


entries and places them into TXT records. 
It also includes RLD records for them. For 
an external reference address constant, 


NADOUT also includes a type 2 ESD record in 
addition to the TXT and RLD records. 
NADOUT outputs temporaries and generated 
constants in TXT records. It does not 
accompany them with RLD records. 


NADOUT does not process address con- 
stants for statement numbers and for state- 
ment numbers appearing in computed GO TO 
statements at this time. However, it re- 
serves storage for them within the “address 
constants" section of text information. It 
does this by incrementing the location 
counter by the number of address constants 
set aside for such items times four. The 
value of the updated location counter is 
then assigned as the relative address of 
the "prologue" if a subprogram is being 
compiled or of the “instructions" if a main 
program is being compiled. 


As previously stated, the values to be 
placed into the address constants for 
statement numbers and statement numbers in 
computed GO TO statements are determined 
during text conversion, when that process 
encounters the END statement. 


Phase 15 Data Text Processing 


The phase 25 subroutine DATOUT assigns 
the initial values specified for variables 
and arrayS in phase 15 data text in the 
following manner: 


1. The relative address of the variable 
or array to be assigned an initial 
value or values is obtained and placed 


into the address field of a TXT 
record. 
2. Each constant (one per variable) that 


has been specified as an initial value 
for the variable or array is then 
obtained and entered into the TxT 
record. (A number of TXT records may 
be required if an array is being 
processed.) 


Such action effectively assigns the ini- 
tial value, because the relative address of 
the initial value has been set to equal the 
relative address of its associated variable 
or array element. 


Prologue and Epilogue Generation 
Phase 25 generates the machine code: (1) 


to transmit parameters to a subprogram, and 
(2) to return control to the calling rou- 
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tine after execution of the subprogram. 
Parameters are transmitted to the subpro- 
gram by means of a prologue. Return is 
made to the calling routine by means of an 
epilogue. Prologues and epilogues are pro- 
vided for subprogram secondary entry points 
as well as for the main entry point. 


Prologue: A prologue (generated by subrou- 
tine PROLOG) is a series of load and store 


instructions that transmit the values of 
"call by value" parameters and the address- 
es of “call by name" parameters to the 
subprogram. (These parameters are 
explained in the publication IBM System/360 


Operating System: FORTRAN IV.) 


When subroutine PROLOG generates a pro- 
logue, it enters the prologue into fTxT 
records and inserts its relative address 
into the address constant reserved for the 
prologue address during the generation of 


initialization instructions. 


Epilogue: An epilogue (generated by sub- 
routine EPILOG) is a series of instructions 
that (1) return to the calling routine the 
values of “call by value" parameters (if 
any), (2) restore the registers of the 
calling routine, and (3) return control to 
the calling routine. (If “call by value" 
parameters do not exist, an epilogue con- 
sists of only those instructions required 
to restore the registers and to return 
control.) 


When subroutine EPILOG generates an epi- 
logue, it enters the epilogue into TXT 
records and inserts its relative address 
into the address constant reserved for the 
epilogue address during the generation of 
initialization instructions. (When phase 
25 encounters the text representation of a 
RETURN statement, a branch to the epilogue 
is generated.) 


Residence of Prologues and Epilogues: The 
prologues and epilogues for secondary entry 


points do not reside in the "Prologue and 
Epilogue" section of text information (see 
Figure 11). This section is reserved for 
the prologue and epilogue of the main entry 
point. The prologue and epilogue for a 
secondary entry point into a subprogram are 
generated immediately after the secondary 
entry coding for the secondary entry point, 
and reside in the "Instructions" section of 
the text information following the secon- 
dary entry coding. 


Text Conversion 


The final function of phase 25 is the 
conversion of intermediate text into Oper- 
ating System/360 machine code. (The text 
conversion process is controlled by subrou- 
tine MAINGN.) In converting the text, 
phase 25 obtains each text entry and, 
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depending upon the nature of the operator 
in the text entry, passes control to one of 
seven processing paths to convert the text 
entry. 


The seven processing paths are: 


Statement Number Processing. 
ENTRY Statement Processing. 
I/O Statement Processing. 
CALL Statement Processing. 
Code Generation. 

RETURN Statement Processing. 
END Statement Processing. 


The logic of text conversion is illus- 


trated in Chart 22. 


STATEMENT NUMBER PROCESSING: When the 
operator of the text entry indicates a 
statement number, MAINGN passes control to 
subroutine LABEL. LABEL then inserts the 
current value of the location counter, 
which is the relative address of the state- 
ment associated with the statement number, 
into the address constant for the statement 
number. When the associated statement is 
converted to machine code and placed into 
text information, it resides at an address 
equal to the value placed into the address 
constant. All branches to that statement 
are effected through the use of the address 
constant. 


Note: If branching optimization is being 
implemented, only statement number that can 
not be branched to via RX format branch 
instructions (i.e., statement numbers that 
are not within the range of registers 13, 


11, 10, and 9) are processed as described 
above. 

After the relative address has been 
placed into the address constant for the 


statement number, Subroutine LABEL deter- 
mines if that statement number appears in a 
computed GO TO statement. If it does, 
LABEL also inserts the relative address 
into the appropriate field of the branch 
table entry, or entries, for that statement 
number. The relative address recorded in 
the branch table entry is placed into the 
storage reserved for it within text infor- 
Mation (refer to "Adcon Table Processing") 
when the text representation of the END 
statement is encountered. 


ENTRY STATEMENT PROCESSING: When the oper- 
ator of an intermediate text entry indi- 
cates an ENTRY statement, subroutine MAINGN 
passes control to subroutines ENTRY, PRO- 
LOG, and EPILOG. These subroutines gener- 
ate the following for the subprogram secon- 
dary entry point: 


e Subprogram 
(refer to the 
Instructions"). 


secondary 
section 


entry coding 
"Initialization 


e Prologue and epilogue (refer to 
"Prologue and Epilogue Generation"). 


The machine code instructions that con- 
stitute the above are entered into TXxT 
records. 


I/O STATEMENT PROCESSING: When the opera- 


tor of the text entry indicates an I/0 
statement, an I/O list item, or the end of 
an I/O list, MAINGN passes control to 
subroutine IOSUB, which generates an 


appropriate calling sequence to IHCFCOMH to 
perform, at object-time, the indicated 
operation. 


The calling sequence generated for an 
I/O statement depends on the type of the 
statement (e.g., READ, BACKSPACE). The 
calling sequence generated for an I/O list 
item depends on the I/O statement type with 
which the list item is associated and on 
the nature of the list item, i.e., whether 
the item is a variable or an array. The 
calling sequence generated for an end of an 
I/O list depends on whether the end I/0 
list operator signals: 


e The end of an I/O list associated with 
a READ/WRITE requiring a FORMAT state- 
ment. 


® The end of an I/O list associated with 


a READ/WRITE not requiring a FORMAT 
statement. 
Once the calling sequence is generated, 


subroutine IOSUB enters it into TXT 


records. 


CALL STATEMENT PROCESSING: When the opera- 
tor of the text entry indicates a CALL 
statement, MAINGN passes control to subrou- 
tine CALLER to generate a standard direct- 
linkage calling sequence, which uses 
general register 1 as the argument reg- 
ister. The argument list is located in the 
adcon table in the form of address con- 
Stants. Each address constant for an argu- 
ment contains the relative address of the 
argument. CALLER enters the calling 
sequence into TXT records. 


CODE GENERATION: 
text entries having operators 
those for statement numbers 


Code generation converts 
other than 
and ENTRY, 


CALL, I/O, RETURN, and END statements into 
System/360 machine code. To convert the 
text entry, code generation uses four 
arrays and the information in the text 


entry. The four arrays are: 

e Register array. This array is reserved 
for register and displacement informa- 
tion. 


e Directory array. This array contains 
pointers to the skeleton arrays and the 


Section 2: 


bit strip arrays associated with opera- 
tors in text entries that undergo code 
generation. 


e Skeleton array. A skeleton array 
exists for each type of operator in an 
intermediate text entry that is to be 
processed by code generation. The 
skeleton array for a particular opera- 
tor consists of a11 the machine code 
instructions, in skeleton form and in 
proper sequence, needed to convert the 
text entry containing the operator into 
machine code. These instructions are 
used in various combinations to produce 
the desired object code. (The skeleton 
arrays are shown in Appendix C.) 


°e Bit strip array. A bit strip array 
exists for each type of operator in a 
text entry that is to undergo code 
generation. The bit strip array for a 
particular operator contains strips of 
bits. One strip is selected for each 
conversion involving the operator. The 
bits in each strip are preset (either 
on or off) in such a fashion that when 
the strip is matched against the skele- 
ton array, the strip indicates the 
combination of instructions that is to 
be used to ccnvert the text entry. 
(The bit strip arrays are shown with 
their associated skeleton arrays in 
Appendix C.) 


In code generation, the actual base 
registers and operational registers (i.e., 
registers in which calculations are to ke 
performed), assigned by phase 20 to the 
operands of the text entry to be converted 
to machine code, are obtained from the text 
entry and placed into the register array. 
Any displacements needed to load the base 
addresses of the operands are also placed 
into the register array. The displacements 
referred to in this context are the dis- 
placements of the base addresses of the 
operands from the start of the adcon table 
that contains the base addresses. These 
displacements are obtained from the infor- 
Mation table entries for the operands. 
This action is taken to facilitate subse- 
quent processing. 


The operator 
converted is used as an 


of the text entry to be 
index to the 


directory array. The entry in this direc- 
tory array, which is pointed to by the 
operator index, contains pointers to the 


Skeleton array and the bit 
associated with the operator. 


Strip array 


The proper bit strip is then selected 


from the bit strip array. The selection 
depends on the status of operand 2 and 
operand 3 of the text entry. This status 


is set up by phase 20 and is indicated in 
the text entry py four bits (see Appendix 
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A, "Phase 20 Intermediate Text 
Modifications"): the first two bits indi- 
cate the status of operand 2; the second 
two bits indicate the status of operand 3. 


The status of operand 2 and/or operand 3 
can be one of the following: 


00 The operand is in main storage and 
is to remain there after the present 
code generation. Therefore, if the 
operand is loaded into a register 
during the present code generation, 
the contents of the register can be 


destroyed without concern for the 
operand. 
01 The operand is in main storage and 


is to be loaded into a register. 
The operand is to remain in that 
register for a subsequent code gen- 
eration; therefore, the contents of 
the register are not to be de- 
stroyed. 


10 The operand is ina register as a 
result of a previous code genera- 
tion. After the register is used in 
the present code generation process, 
its contents can be destroyed. 


11 The operand is in a register and is 
to remain in that register fora 
subsequent code generation. The 
contents of the register are not to 
be destroyed. 


This four bit status field is used as an 
index to select a bit strip from the bit 
strip array associated with the operator. 
The combination of instructions indicated 
in the bit strip conforms to the operand 
status requirements: i.e., if the status of 
operand 2 is 11, the generated instructions 
make use of the register containing operand 
2 and do not destroy its contents. The 
combination, however, excludes base load 
instructions and the store into operand 1. 

Once the bit strip is selected, it is 
moved to a work area. The strip is modi- 
fied to include any required base load 
instructions. That is, bits are set on in 
the appropriate positions of the bit strip 
such that, when the strip is matched to the 
skeleton array, the appropriate instruc- 
tions for loading base addresses are 
included in the object code. The skeletons 
for these load instructions are part of the 
skeleton array. 


The code generation process determines 
if the base address of operand 2 and/or 
operand 3 must be loaded into a register by 
examining the status of these base address- 
es in the text entry. Such status is 
indicated by four bits: the first two bits 
indicate the status of the base address of 
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operand 2; the Second two bits indicate the 
Status of the base address of operand 3. 
If this status field indicates that a base 
address is to be loaded, the appropriate 
bit in the bit strip is set on. (The bit 
to be operated upon is known, because the 
format of the skeleton array for the opera- 
tor is known.) 


Before the actual match of the bit strip 
to the skeleton array takes place, the code 
generation process determines: 


e If the base address of operand 1 must 
be loaded into a register. 


e If the result producea by the actual 
machine code for the text entry is to 
be stored into operand 1. 


This information is again indicated in the 
text entry by four bits: the first two bits 
indicate the status of the base address of 
operand 1; the second two bits indicate 
whether or not a store into operand 1 is to 
be included as part of the object code. If 
the base address of operand 1 is to be 
loaded and/or if operand 1 is to be stored 
into, the appropriate bit(s) in the bit 
Strip is set on. 


The bit strip is then matched against 
the skeleton array. Each skeleton instruc- 
tion corresponding to a bit that is set on 
in the bit strip is obtained and converted 
to actual machine code. The operation code 
of the skeleton instruction is modified, if 
necessary, to agree with the mode of the 
operand of the instruction. The mode of 
the operand is indicated in the text entry. 
The symbolic base, index, and operational 
registers of the skeleton instructions are 
replaced by actual registers. The base and 
operational registers to be used are _ con- 
tained in the register array. If an oper- 
and is to be indexed, the index register to 
be used is obtained. (The index register 
is saved during the processing of the text 
entry whose operand 1 represents the actual 
index value to be used.) The displacement 
of the operand from its base address, if 
needed, is obtained from the information 
table entry for the operand. (The contents 
of the displacement field are added to this 
displacement if a subscript text entry is 
being processed.) These elements are then 
combined into a machine instruction, which 
is entered into a TXT record. (If the 
skeleton instruction that is being convert- 
ed to machine code is a base load instruc- 
tion, the base address of the operand is 
obtained from the object-time adcon table. 
The register (13) containing the address of 
the adcon table and the displacement of the 
operand's base address from the beginning 
of the adcon tabie are contained in the 
register array.) 


Branch Processing: The code generation 
portion of phase 25 generates the machine 
code instructions to complete branching 
optimization. The processing performed by 
code generation, if branching optimization 
is being implemented, is essentially the 
same as that performed to produce an object 
module in which branching is not optimized. 
However, before a skeleton instruction 
(corresponding to an on bit in the selected 
and modified bit strip) is assembled into a 
machine code instruction, code generation 
determines if that instruction either: 


e Loads into a register the address of an 
instruction to which a branch is to be 
made and which is displaced less than 
4096 bytes from the address ina re- 
served register?. 


e Is an RR-format branch instruction that 
oranchés to an instruction that is 
displaced less than 4096 bytes from the 
address in a reserved register?. 


Note: A load candidate usually immediately 
precedes a branch candidate in the skeleton 
array. 





Code generation determines if the 
instruction to pe branched to is displaced 
less than 4096 bytes from an address in a 
reserved register by interrogating an indi- 
cator in the statement number entry for the 
statement number associated with the block 
containing the instruction to be branched 
to. This indicator is set by phase 20 to 
reflect whether or not that block is dis- 
placed less than 4096 bytes from an address 
in a reserved register. 


The completion of branching optimization 
proceeds in the following manner. Ifa 
skeleton instruction corresponding to an on 
bit in the bit strip is a load condidate, 
it is not included as part of the instruc- 
tion sequence generated for the text entry 
under consideration. If a skeleton 
instruction corresponding to an on bit in 
the bit strip is a branch candidate, it is 
converted to an RX-format branch instruc- 
tion. The conversion iS accomplished by 
replacing operand 2 (a register) of the 
branch candidate with an actual storage 
address of the form D (0,Br). D represents 
the displacement of the instruction (to be 
branched to) from the address that is in 
the appropriate reserved register (Br). 


If the instruction to be branched to is 
the first in the text block, both the 
displacement and the reserved register to 


1This type of text entry is subsequently 
referred to as a load candidate. 

2This type of text entry is subsequently 
referred to as a branch candidate. 
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be used for the RX-format branch 
Obtained from the statement number 
associated with the block containing the 
instruction. (This information is placed 
into the statement number entry during 
phase 20 processing.) 


are 
entry 


If the instruction to be branched to is 


one that is subsequently to be included as 


part of the instruction sequence generated 
for the text entry under consideration?, 
the displacement of the instruction from 


the address in the appropriate reserved 
register is conputed and used as the dis- 
placement of the RX-format branch instruc- 
tion. The reserved register used in such a 
case is the one indicated in the statement 
number entry associated with the block 
containing the text entry currently being 
processed by code generation. 


RETURN STATEMENT PROCESSING: When the 
Operator of the text entry indicates a 
RETURN statement, MAINGN passes control to 
subroutine RETURN, which generates a branch 
to the epilogue. The epilogue address is 
obtained from the subprogram save area. 
The address of the epilogue is placed into 
the save area during the execution of 
either the subprogram main entry coding or 
the subprogram secondary entry coding 
(refer to the section "Initialization 
Instructions"). 


END STATEMENT PROCESSING: When the opera- 
tor of the text entry indicates an END 
statement, MAINGN passes control to subrou- 
tine END, which completes the processing of 


the module by entering the address’ con- 
Stants (i.e., relative addresses) for 
Statement numberS and statement numbers 


appearing in computed GO TO statements into 
text information and by generating loader 
END loader record. 


Subroutine END enters the address con- 
stant (i.e., relative address) for each 
Statement number and for each statement 
number in a computed GO TO statement into a 
TXT record. The address inserted into each 
such record places the address constant 
into the storage reserved for it during 
ADCON table processing. ; 


The loader END record must be the last 
record of the object module. Its functions 
are to signal the end of the object module 
and to inform the linkage editor of the 
Size (in bytes) of the control section and 
the address of the main entry point of the 
control section. 


3Skeleton arrays for certain operators con- 
tain RR format branch instructions that 
transfer control to other instructions of 
that skeleton. 
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EXTERNAL SYMBOL DICTIONARY 


The external symbol dictionary contains 
entries for external symbols that are 
defined or referred to within the module. 
An external symbol is one that is defined 
in one module and referred to in another. 
One external symbol dictionary entry (an 
ESD record) is constructed by phase 25 for 
each external symbol it encounters. The 
entry identifies the symbol by indicating 


its type and .location within the moduie. 

The ESD records constructed by phase 25 

are: 

e ESD-0 This is a section definition 
record for the source module being 
compiled. 

e ESD-1 This record defines an entry point 
for the source module being com- 
piled. 

® ESD-2 This record is generated for an 
external subprogram name. 

e ESD-5 This is a section definition 


record for a common block (either 
named or blank). 


For a more complete discussion of the 
use and the format of these records, refer 


to the publication IBM System/360 Operating 


System: Linkage Editor, Program Logic Manu- 
al. 


RELOCATION DICTIONARY 


The relocation dictionary is composed of 
entries for the address constants of the 
object module. One relocation dictionary 
entry (an RLD record) is constructed by 
phase 25 for each address constant it 
encounters. If the address constant is for 
an external symbol, the RLD record iden- 
tifies the address constant by indicating: 
the 


e The control section to which 


address constant belongs. 


e The location of the address constant 
within the control section. 


e The symbol in the external symbol dic- 
tionary whose value is to be used in 


the computation of the address con- 
stant. 
If the address constant is for a local 


symbol (i.e., a symbol that is located in 
the same control section as the address 
constant), the RLD record identifies the 
address constant by indicating the control 
section to which the address constant 
belongs and its location within that con- 
trol section. 
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For a more detailed discussicn of the 
use and format of an RLD record, refer to 


the publication IBM System/360 Operating 


System: Linkage Editor, Program Logic Manu- 
al. 


PHASE 30 


Phase 30 records (on the SYSPRINT data 
set) appropriate messages for syntactical 
errors encountered during the processing of 
phases 10 and 15; its overall logic is 
iliustrated in Chart 23. As errors are 
encountered by these phases, error table 
entries are created and piaced into an 
error table. Each such entry consists of 
two parts: the first part contains either 


an internal statement number, if the entry 
is for a statement that is in error, a 
dictionary pointer to a variable, if the 


entry is for a variable that is in error, 
or an actual statement number, if the entry 
is for a non-defined statement number; the 
second part contains a message number. (If 
the error cannot be localized to a particu- 
lar statement, no internal statement number 
is entered in the error table entry. Phase 
30 simulates the internal statement number 
with a zero.) 


Message Processing 


Using the message number in the error 
table entry multiplied by four, phase 30 
locates, within the message pointer table 
(refer to Appendix A, "Diagnostic Message 
Tables"), the entry corresponding to the 
message number. This message pointer table 


entry contains (1) the length of the mes- 
sage associated with the message number, 
and (2) a pointer to the text of the 


message associated with the message number. 
After phase 30 obtains the pointer to the 
message text, it constructs a parameter 
list, which consists of: 


e Either the internal statement number, 
dictionary pointer, or statement number 
appearing in the error table entry. 


e A pointer to the message text associat- 
ed with the message number. 


e The length of the message. 
e The message number. 


constructed the parameter list, 
calis subroutine MSGWRT, which 
the message on the SYSPRINT data 
set. After the message is written, the 
next error table entry is obtained and 
processed as described above. 


Having 
phase 30 
writes 


As each error table entry is being 
processed, the error level code (either 4 


or 8) associated with the message number is use only if it is greater than the error 
obtained from the error code table level codes associated with message numbers 
(GRAVERR) by using the message number in appearing in previously processed error 
the error table entry as an index. The table entries. Thus, after all error table 
error level code indicates the seriousness entries have been processed, the highest 


of the encountered error. (See the publi- error level code (either 4 or 8) has been 
cation IBM System/360 Operating System: saved. The saved error level code is 
FORTRAN IV Programmer's Guide for explana- passed to the FSD when phase 30 processing 


tions of all the messages capable of being is completed. This code is used by the FSD 
generated by the compiler.) The obtained to determine whether or not the compilation 
error level code is saved for subsequent is to be deleted. 
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Subroutine] 


GETCOR 


IEKAA00 


TEKAREAD 


ITEKFCOMH 


TEKFIOCS 


IEKUATPT 


IHCFMAXT 


THCFMAXR 


SYSDIR 


SYSTAB 


S¥YSTRC 


FSD Subroutine Directory 


Exponentiation of integers by integers. 
Exponentiation of reals by integers. 


Allocates and keeps track of main storage used in the construction of the 
information table and for collecting text entries. 


Initializes compiler processing and calls the phases for execution. 


Works in conjunction with SYSDIR to delete a compilation. It reads 
records (without processing them) until an END statement is encountered. 


Controls compile-time I/0. (Corresponds to IHCFCOMH; refer to Appendix 
E.) 


Interface between IEKFCOMH and BSAM. (Corresponds to IHCFIOSH; refer to 
Appendix E.) 


Unit assignment table for IEKFIOCS. 
Maximizing service routine for integers. 
Maximizing service routine for reals. 
Deletes compilation if requested. 

Dumps internal text and tables. 


Diagnostic trace routine. 
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Table 7. 


Phase 10 Source Statement Processing 


Seer ee rE Se ee ee ee re ee ee Be 1 
| Main Processing j| | 
| . Statement Type | Subroutine | Subroutines Used | 
}------------------ $------------------- }-----------~------------------------------------ 1 
| ARITHMETIC | XARITH | COMAST, GRPKEQ, MINSLS, PRELOG, RTPROT, TXTBLD+| 
}------------------ }------------------- }------------------------------------------------ { 
| STATEMENT | XASF/XASF2 | GETWD, ERROR, PUTX, CSORN, SYMTLU | 
| FUNCTION | | | 
}------------------ }-----------------=- to-----------~-------+--------------------------- { 
| DIMENSION {| XDIM | GETWD, CSORN, ERROR, SYMTLU | 
}------------------ }------------------- }------------------------------------------------ { 
{ EQUIVALENCE | XEQUI | GETWD, SYMTLU, ERROR, LITCON | 
[---------~------—- $-------—----—--——- }---~----~---~--~-------------------------------- { 
{| COMMON _ |  XCOMON | GETWD, SYMTLU, ERROR | 
pono +-- = fame nn meant fanaa ann nn nn nn n  nn { 
| EXTERNAL | XEXT | GETWD, ERROR, SYMTLU | 
fama ene nnn {——-— fran naan nn nnn nnn nnn nn nnn nnn { 
| TYPE (INTEGER, | XTYPE | GETWD, ERROR, SYMTLU, PUTX | 
{| REAL, ETC.) | | | 
}-------~---------- jo------ === }-----~--~--~---------------~-------------------- { 
{| DO | xXDO | GETWD, ERROR, LITCON, SYMTLU, PUTX, CDOPAR | 
}------------------ ------------------- fn----------—--------- === +--+ : 
| SUBROUTINE, CALL| XSUBPG | GETWD, ERROR, SYMTLU, PUTX | 
| ENTRY, FUNCTION | | { 
}---~-------------- fomeaa aaa fone nn an nnn + == = --------- { 
{| READ, WRITE, | XIOOP | GETWD, ERROR, CSORN, PUTX, LITCON | 
| PRINT, PUNCH | j | 
fon nnn nnn fo-=----=----------- fn nnn nn nn nn nn { 
| NAMELIST | XNMLST | GETWD, SYMTLU, PUTX, ERROR | 
}------------------ fr mamn nnn fon nnn nnn nn enn ean} 
| BACKSPACE, | | | 
| REWIND, | XBCKRW | GETWD, SYMTLU, PUTX, ERROR | 
| END FILE | | | 
pon—-a=~——--—=--—- fomann nnn nan ann n= }--------~--~-~~--------------------------------- { 
| RETURN | XRETN | GETWD, CSORN, ERROR, PUTX | 
ac ae eager fama nnn nn nnn nnn nnn nnn nen : 
| IF | XIF | PUTX, ERROR 
prona nea n | pEasars Re RaESEEE | eee { 
| ASSIGN | XASGN | GETWD, LITCON, ERROR, SYMTLU, PUTX | 
poma nnn s Soap $—-~-~—----------------------- === - === === === == : 
} BLOCK DATA | XBLOK | PUTX, ERROR | 
}-------——----~---- fomnnn manne nena fn nnn nnn nn nnn : 
| FORMAT | X¥FMT | CSORN, PUTX | 
pena nna nnn nnn ee eae fama nnn nnn nnn nnn nn nnn nnn 1 
| CONTINUE | XCONT | ERROR, PUTX | 
prem manne nnn Ie ol aR fanaa nnn nnn nnn nnn nnn nn nnn nnn nnn { 
]} GO TO | xGO | GETWD, ERROR, SYMTLU, LITCON, PUTX | 
frm men Sa fn nn nee nee { 
| DATA | XDATA | GETWD, CSORN, ERROR, PUTX | 
Se aoa Pn ea eee { 
| STOP | XSTOP | PUTX | 
pena nnn nnn nnn f-----------— === === fn nnn nnn nnn nn nnn nen nnn { 
{| PAUSE | XPUSE | GETWD, ERROR, CSORN, PUTX | 
}-------—---------- fomeen an nnn nnn anne }-------~--=----------- =~ - === === === { 
| END | XEND | ERROR, PUTX | 
p—-——..—- He ocites aeeia  e s See ee Se ee a ee eee ea! | 
| +2+The subroutines used by subroutine XARITH employ the following utility subrou- | 
| tines: GETWD, CSORN, PUTX, COMPAT, ERROR, and SYMTLU. | 
Pose Soe ek ee ae a a le ee re J 
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Table 8. Phase 10 Subroutine Directory 
Ce Rg ee are 
| Subroutine] Type 
eee f——-~--—— +--+ ----~--- 
| CDOPAR {Utility (entry placement) 
| | 

| | 

i I 

| Bec aeteeaad 

| COMAST | Arithmetic 

| | 

| | 

| | 

| Bot 
| COMPAT |Utility (collection) 

{ | 

| Vey co 2 : 
| CLOSE JUtility (text generation) 
i | 

| | 

| oe 

| CSORN [Utility (entry placement) 
| | 

| [ 

| DSPTCH | Dispatcher 

| | 

| | 

| I 

| { 

| | 

| I 

| Tats ie 

| ERROR jUtility (entry placement) 
| | 

| | 

| eee 
| GENDO {Utility (text generation) 
| | 

| | 

| | 

| GETCD | Preparatory 

| | 

ore 7 
| GETWD JUtility (collection) 

| | 

| Wee tortes-1 w,: 

| GRPKEQ | Arithmetic 

I | 

| | 

| | 

| ee 
| INTCON {Utility (conversion) 

| | 

| | 

| ae 

| LABTLU {Utility (entry placement) 
| | 

| Wee ee 
| LITCON {Utility (conversion) 

| i 

| Ben ett ahs 

| MINSLS {Arithmetic 

| i 

{ | 

| | 
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+—4 


a ee ce ae ee ae ne cn me me me cc ee ce ee ee ce a ee ae ee ee ee ee ee ee ee ee 


Function 


Constructs information table entries and 
pushdown table entries for the index ini- 
tial value, index increment, and index 
maximum value appearing in DO statements. 


Develops intermediate text and builds 
information table entries for variabies 
and constants connected by a comma or an 
asterisk delimiter. 


Places variable names on word poundaries 
for comparison to other variable names. 


Generates the text entry that signifies 
the end of the intermediate text represen- 
tation of a source statement. 

Directs the entering of variables ana 
constants into tne information table. 


Control phase 10 processing, passes con- 
trol to the preparatory subroutine to 
prepare the source statement, determines 
from the code assigned to the statement 
which subroutine is to continue processing 
the statement and passes control to that 
subroutine. 


Builds error table entries for the syntac- 
tical errors detected by phase 10 and 
places them into the error table. 


Generates the intermediate text required 
to increment a DO index and to test the 
index against its maximum. 


Reads, lists (if requested), packs, and 
classifies each source statement. 

Obtains the next group of characters in 
the source statement being processed. 

Develops intermediate text and builds 
information table entries for variables 
and constants connected by an equal sign 
Or a group mark (end of statement symbol). 


Calls subroutine LITCON to convert a con- 
stant and then verifies that the converted 
constant is of integer mode. 

the 


Places statement number entries into 


information table. 


Converts integer, real, and complex con- 
stants to their binary equivalents. 


Develops intermediate text and builds 
information table entries for variables 
and constants connected by a minus or 
Slash delimiter. 


1 
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Table 8. Phase 10 Subroutine Directory (Continued) 


ea ge ee re tee a a a a a AL ae a a Ba 7 
| Subroutine | Type | Function | 


Besa SSS eo eee eee eee 4 
Develops intermediate text and builds 
information table entries for variables 
and constants connected by a period delim- 
iter. 


Arithmetic 


rd 
ea 
P<] 
ai 
OQ 
Q 


PH10 Utility (common data area) Phase 10 COMMON area. 


PH10A tility (common data area) Phase 10 COMMON area. 


a a 


PUTX tility (entry placement) Places text entries into the appropriate 
sub-blocks, obtains the next operator of 
the source statement, and places the oper- 
ator into the text entry work area. 

RTPROT Arithmetic Develops intermediate text and builds 
information table entries for variables 
and constants connected by a right paren- 
thesis or a quote delimiter. 

SYMTLU Utility (entry placement) Places the dictionary entries constructed 
for the variables and constants of the 
source module into the information table. 
TXTBLD Arithmetic Develops intermediate text and builds 
information table entries for variables 
and constants connected by a left paren- 
thesis, or for complex constants. 

XARITH Arithmetic Controis the processing of arithmetic 
Statements, CALL arguments, expressions 
appearing in IF statements, I/0 list 
items, Simple variable and array names 
appearing in NAMELIST statements, complex 
literals appearing in DATA statements, and 
arithmetic expressions appearing in state- 
ment functions. Subroutine XARITH scans 
the expression and passes control to one 
of the following supporting subroutines, 
depending on the nature of the delimiter 
recognized: COMAST, GRPKEQ, MINSLS, PER- 
LOG, RTPROT, and TXTBLD. 

Arithmetic Scans the portion of a statement function 
to the left of the equal sign, obtains 
each dummy argument, and assigns it a 
sequence number. 

XASF2 Arithmetic Insures that ali dummy arguments appearing 
in the argument list of a statement func- 
tion are used in the expression to the 
Yight of the equal sign in that statement 
function. 

XASGN Key Word (table entry and text)| Develops an intermediate text representa- 
tion of the ASSIGN statement, constructs 
information table entries for its oper- 
ands, and analyzes the ASSIGN statement 
for syntactical errors. 
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fr me mr cc ne ee ee cee ce nee re cee ee ee nee SS ene OE ee Ge A cee SOR I ED OE GREE NS SR SD OS OE SS SS EE CO ES SN A RS SS SEY mes Se ons cents concen amor 


pe mn er es cr ee re cr ce es re es es ee ee es tee He eee cD A SS NS SS SY SS SN NS A ONS SD SN GN Ge EN NS SS eS Se cee ea So Sane 
fee eevee menses comens Stones somes SEMAN Genes GRE cemee GSE Gee AONE TEE UTS ONSET MNS SY cence ONS seeey GEE Gee ce A apes SES Gaps eS eS IES Meat gee GUNIRS SED a SO GANS STN Ge AD gees ES ES me ON ee NY ee SE pe SS ee A ees a oe 


Section 2: Discussion of Major Components 79 


Table 8. Phase 10 Subroutine Directory (Continued) 


oo ee re ee ee a a aS a a 1 
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a 
Subroutine | 


Key Word (table entry and text) 


XBCKRW 
. XBLOK 


XCLASS 
XCOMON 
XCONT 


XDATA 


XDIM 


XDO 
XEND 


XEQUI 


| 
i 
| 
| 
| 
[ 
| 
| 
i 
| 
| 
| 
| 
i 
| 
i 
| 
| 
l 
| 
| 
l 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
I 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
{ 
| 
[ 
I 
| 
| 
| XEXT 
l 

| 

| 
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Word 


x 
@ 
he 


word 


ra 
10) 
he 


Word 


x 
0) 
he 


Word 


K 
@ 
h< 


Word 


x 
© 
hg 


Word 


x 
@ 
h< 


Word 


x 
) 
M< 


Key Word 
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Key Word (table entry and text) 


Utility (text generation) 


(table 


(table 


(table 


(table 


(table 


(table 


(table 


(table 


entry) 


entry and text) 


entry and text) 


entry) 


entry and text) 


entry and text) 


entry) 


entry) 


Function 


Develops intermediate text representations 
of the BACKSPACE, REWIND, and END FILE 
statements, builds information table 
entries for the operands of these state- 
ments, and analyzes these statements for 
syntactical errors. 


Develops an intermediate text representa- 
tion of the BLOCK DATA statement, set a 
switch in the communication table to indi- 
cate that a BLOCK DATA subprogran is being 
compiled, and analyzes the BLOCK DATA 
statement for syntactical errors. 


Generates intermediate text for statement 
numbers. 


Constructs information table entries for 
block names, variables, and arrays appear- 
ing in COMMON statements, chains common 
block name entries and associated varia- 
bles and arrays togetner, and analyzes 
COMMON statements for syntactical errors. 


Develops and intermediate text representa- 
tion of the CONTINUE statement, and veri- 
fies that there is a statement number 
associated with it. 


Develops an intermediate text representa- 
tion of the DATA statement, constructs 
information table entries for the operands 
of the DATA statement, processes the data 
specifications in TYPE statements, and 
analyzes DATA statements for syntactical 
errors. 


Constructs information table entries for 
the arrays appearing in DIMENSION, COMMON; 
and TYPE statements, and analyzes arrays 
for syntactical errors. 


Develops, with the aid of subroutines 
CDOPAR and GENDO, the intermediate text 
required to control a DO loop. 


Develops an intermediate text representa- 
tion of the END statement and analyzes the 
END statement for syntactical errors. 


Builds information table entries for 
equivalence groups and their associated 
variables, chains equivalence groups and 
associated variables together, and ana- 
lyzes EQUIVALENCE statements for syntacti- 
cal errors. 


Constructs information table entries for 
the subprogram names appearing in the 
EXTERNAL statement, signals the subpro- 
grams as external, and analyzes the EXTER- 
NAL statement for syntactical errors. 
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hase 10 Subroutine Directory (Continued) 


a 
Subroutine| Type | 
[--------— }------------------------------- }—----------—___----------------------—---- { 


XIF 
XIMPC 


XIMPD 


XIOOP 
XNMLST 


XPUSE 
XRETN 


| 
| 
| 
| 
| 
| 
| 
{ 
| 
| 
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| 
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| 
| 
| 
| 
| 
| 
| 
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| 
| 
| 
| 
| XSTOP 
| 

| 

| 

| 


XSTRUC 
ba a em we 


|Key Word (table entry and text) | 


ea 
(0) 
he 


Word (table entry and text) 


Key Word (table entry and text) 


Key Word (special) 


Utiltiy (text generation) 


Key Word (table entry and text) 


Key Word (table entry and text) 


Key Word (table entry and text) 


Key Word (table entry and text) 


Key Word (table entry and text) 


rm cee ne et ee ee ee Se Se SS REE SN SS MD SRNR eee EN Se SS SS LS NN SS SO NE SS SER SY A SN ES SN A SS A SE SS a SNL eS SD SN eS See ee eee 


Function 


Develops an intermediate text representa- 
tion of the FORMAT statement. 


Develops intermediate text representations 
of the GO TO (unconditional, assigned, and 
computed) statements, constructs informa- 
tion table entries for the operands of 
these statements, and analyzes these 
statements for syntactical errors. 


Develops an intermediate text representa- 
tion of that portion of IF statements 
which precedes the opening parenthesis and 
passes control to subroutine XARITH to 
complete the processing of these state- 
ments. 


Sets the type of the variables beginning 
with the characters stated in the IMPLICIT 
statement according to the type specifi- 
cations stated in the IMPLICIT statement, 
and analyzes the IMPLICIT statement for 
syntactical errors. 


Develops intermediate text representations 
of implied DO'S appearing in I/O state- 
ments. 


Develops intermediate text representations 
of I/O statements, constructs information 
table entries for their operands, and 
analyzes I/O statements for syntactical 
errors. (I/O list items are processed by 
subroutine XARITH.) 


Develops an intermediate text representa- 
tion of the NAMELIST statement and con- 
structs information table entries for its 
operands. (Passes control to subroutine 
XARITH to process the simple variable of 
array names.) 


Develops an intermediate text representa- 
tion of the PAUSE statement, constructs 
information table entries for its operands 
(if any), and analyzes the PAUSE statement 
for syntactical errors. 


Develops an intermediate text representa- 
tion of the RETURN statement, constructs 
information table entries for its operands 
(if any), and analyzes the RETURN state- 
ment for syntactical errors. 


Develops an intermediate text representa- 
tion of the STOP statement and analyzes 
that statement for syntactical errors. 


Dummy key word subroutine. 
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Phase 10 Subroutine Directory (Continued) 
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of CALL, 
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process 
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SUBROUTINE, 
statements, constructs 
entries for the operands of these 
analyzes these statements for 
subroutine 
XARITH to 


appearing in CALL 


syntactical 
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arguments 


of TYPE statements, 
table entries for their 
analyzes the TYPE statements for syntacti- 


cal errors. 
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| 
L 


Function 


Develops intermediate text representations 
and FUNCTION 
information tabie 


errors. 
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Chart 07. ALTRAN Control Flow 
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NOTE: The logic and flow of the arithmetic translator is too complex to be represented on one or two conventional 
flowcharts. Chart 07 indicates the relationship between the arithmetic translator (subroutine ALTRAN) and its lower- 
level subroutines. An arrow flowing between two subroutines indicates that the subroutine at the origin of the 
arrow may, in the course of its processing, call the subroutine indicated by the arrowhead. In some cases, a sub- 
routine called by ALTRAN may, in turn, call one or more subroutines to assist in the performance of its function. 
The level and sequence of subroutines is indicated by the lines and arrowheads. 





In reality, all of the pathways shown connecting subroutines are two-way; however, to simplify the chart, only 
forward flow has been indicated by the arrowheads. All of the subroutines return control to the subroutine that 
called them when they complete their processing. (If a subroutine detects an error serious enough to warrant the 
deletion of the compilation, the subroutine passes control to the FSD, rather than return control to the sub- 
routine that called it.) 


The specific functions of each of the subroutines associated with the arithmetic translator are given in the sub- 
routine directory following the charts for phase 15. 
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Chart 09. 


CORAL 


88 


* 
* 
* 


HREKADEERRHREER 


FROM FSD 


REKKEKREEREERERE 


* 
* 
* 


HRKKKEAHD HH RERHHERE 


* NDATA * 
HARK H— ME HHH EK 
* PROCESS * 
* DATA * 
* STATEMENTS * 


HREM EEE EREE 





HEKERBGZRHEKKAERER 
* CONST * 
oe oe or ee ee eo 
>*ASSIGN RELATIVE* 
* ADDRESSES * 


* TO CONSTANTS ¥* 
EEE RENEE REE EE 


pennscgereensiner 
* VARA * 
rt oe oe 
*#ASSIGN RELATIVE* 
* ADDRESSES * 


* TO VARIABLES * 
RNR EKHAEHE REE RER EE 


Vv 
MHEKEK OFM ARH REREN 
* EQVAR * 


HEH KEK HHH 
*ASSIGN ADDRESS—* 
*#ES TO EQUIVAL— * 


*ENCE VARIABLES * 
EERE LAKE EREREEER 


Vv 
HKALE ZR EMER RHEE 
* COMVAR * 
ee ee 
*ASSIGN ADDRESS-—* 
* ES TO COMMON * 
* VARYABLES = 
ERR EANEEREE REESE 





v 
HHEDEE ZH RRKRERERE 
* EXTRNL * 


SHE — KE — EK —E 
* COMPLETE REL~ * 
* ATIVE ADDRESS * 


* ASSIGNMENT * 
KEREEREREEREEREEE 


Se re re ee ere et em ene 


-* %e 
o* MAP ee 


CORAL Overall Logic 


NO 


ke OPTION 2t——— 


*eSPECIFIEDe* 
He * 
He ot 

* YES 


v 
MRK J ZRH RRHKEREKE 


* STMAP * 
oe ee ee re ee ee ee ee 
* GENERATE * 
* STORAGE * 
* MAP * 


MEARE H EKER EREH 


| 
| 
| 


eel 


Vv 
HK KZ HH HEH KEKE 


* * 
* TG FSD * 
* * 


KER KKKKREKEEEERE 


Table 9. Phase 15 Subr 


outine Directory 


f(s" sSr4sS > Tre ee ee ay ee ee ee oe pt er ee a ee ee eg ee 1 
| Associated | | 
|Subroutine|Phase 15 | Function | 
| {| Segment | | 
[---------- }---------- $------------~-—---------------------------------------=-------- { 
| ADSCAN | CORAL | Scans the adcon table for an address constant that references | 
| | {| the relative address computed for a variable. | 
| | | | 
| ALTRAN1 | PHAZ15 | Controls the arithmetic translation process. | 
| | | | 
| ANDOR+ | PHAZ15 | Checks the mode of the arguments passed to it, decomposes IF | 
| | | statements, and generates text entries for AND and OR opera- | 
| | | tions. | 
| | | a ; i 
| ARIF | PHAZ15 | Optimizes the coding derived from the branching portion of an | 
| | | arithmetic IF statement. | 
| | | | 
| BLTNFN+ | PHAZ1i5 | Determines whether or not a given name represents a valid | 
| | | in-line function, and generates phase 15 text for the ref- | 
| | | exenced in-line function. | 
| | | | 
| BSIZE | STALL | Computes the size (in bytes) of a variable or array based on | 
| | | its mode and dimensions (if any). | 
| | | | 
| C1520 | | Common data area used by phases 15 and 20. | 
| | | | 
| CMSIZE {| CORAL | Checks the displacement computed by subroutine SPAN to see if | 
| | | it lies within the range of 0 to 4096 bytes. | 
| | | | 
| COMMD+ | PHAZ15 | Generates the text required for complex multiplication or | 
| | | division (i.e., a call to a library routine). | 
| | | I 
| COMN | STALL | Processes the common table entries constructed by phase 10 for | 
| | | the operands appearing in COMMON statements. | 
| | | | 
| COMVAR | CORAL | Assigns relative addresses to common variables and variables | 
| | | equivalenced into common. | 
| | | | 
| CONST | CORAL | Assigns relative addresses to all constants in the dictionary. | 
| | | | 
| CORAL | CORAL | Controls the relative address assignment function of phase 15. | 
{ | | | 
| CPLTST2 | PHAZ15 | Checks triplets for complex operands and controls text genera- | 
| | | tion for the same. | 
| | | | 
| DATACH | CORAL | Chains the data text created py subroutine NDATA in the order | 
| | | in which it will be processed by phase 25. | 
| | | | 
| DCTSRT | STALL | Sorts the dictionary constructed by phase 10. | 
| | | | 
| DFUNCT+ | PHAZ15 | Determines if a reference is to an in-line, iibrary, or | 
| | | external function, and performs mode checking and automatic | 
| | | typing for library functions. | 
| | | | 
{| DUMP15 | PHAZ15 | Records errors detected during PHAZ15 processing. | 
| | | | 
| EQU | STALL | Establishes a “head" for each equivalence group and computes | 
| | | the displacement of each variable in the group from the group | 
| | | head. | 
| | f : 7 | 
| EQVAR { CORAL | Assigns relative addresses to equivalence variables except | 
| | | those that are equivalenced into common. | 
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Table 9. Phase 15 Subroutine Directory (Continued) 
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Function | 

| 
~~~--------------~-~-------~----------+----------+------=--------] 
Places entries into the error table for errors Getected during | 
the processing of common biocks and equivalence groups. | 
| 

Generates the text required for exponentiation operations. | 
| 

Completes the relative address assignment process by reserving | 
address constants for quantities not previously assigned | 
addresses. | 
| 

Completes the processing required for a statement when its | 
primary adjective code is forced from the pushdown table. | 
| 

Creates pushdown entries for references to implicit library | 
functions. | 
| 

Outputs phase 15 text consisting of unchanged phase 10 text, | 
phase 15 standard text, and phase 15 statement number text. | 
| 

Builds appropriate phase 15 text entries for simple items | 
forced from tne pushdown tabie. | 
| 

Provides susroutine GENER with the main storage needed for a | 
text entry. | 
| 

Creates an abbreviated one-word dictionary entry for temporar- | 
ies. | 
Common data area, which is the FORTRAN supplied subprogram | 
table. 
| 

Scans the statement number entry chain for statement numbers | 
thet are referenced, but not defined. | 
| 

Looks up names in the IFUNTB (subprogram) table. | 
Records usage information in the MVS, MVF, and MVX fields if | 
the complete-optimized path through phase 20 is selected. | 
| 

Changes modes for logical expressions. | 
| 

Checks for mixed-mode conditions in the triplet supplied to it. | 
| 

Converts phase 10 data text to phase 15 data text. | 
| 

Checks for negative operands in the argument list of a function | 
Or in arithmetic IF statements. | 
| 

Determines the forcing strength of operators. | 
| 

Determines if operand 1 is to be an actual operand or a | 
temporary. | 
Removes tne ( or -( from the pushdown table when the corre- | 
sponding ) is encountered. | 
| 

Common data area used by phase 15. i 
| 

Controlling subroutine of PHAZ15 processing. | 
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Table 9. Phase 15 Subroutine Directory (Continued) 


foo tsSs-s> Tosser SSS St nS er eS ra Snr tr ret sats s 1 
{ : | Associated | | 
. |Subroutine|Phase 15 | Function | 
| | Segment | : | 
}-----~---- +-------—- }---------- ~~ ------ ~~ 5-2-2 oan n= { 
{| PHSTAL { | Common data area used during relative address assignment. | 
| | | | 
| POWER2+ | PHAZ1i5 | Determines whether or not the argument passed to it is an | 
{ i {| integral power of two. | 
| | | | 
| PRTEXT |} CORAL | Prints out phase 15 data text. | 
| | | | 
{ RDTST1 | PHAZ15 | Builds text for replacement statements (e.g., A=B, A=B(I), | 
| | { ACI)=B, ACI)=B(I)). | 
| | | i 
| RELOPS? | PHAZ15 | Calls suproutine GENER to output text entries for relational | 
| | | Operators. (Output may be either a relational or branch | 
| | | Operation.) | 
| | | | 
| SBEROR | STALL | Places entries into the error table for errors detected during | 
| | | the processing of COMMON and EQUIVALENCE declarations. | 
| | | | 
| SBGLUT+ | PHAZ15 | Optimizes subscript computations by evaluating subscript con- | 
| | | stants. | 
| | | | 
| SIZE | CORAL | Computes the total size (in bytes) of a variable or constant. | 
| | | | 
| SPAN | CORAL | Computes the span of an array. | 
| | | | 
{ STALL | STALL {| Controlling subroutine of STALL processing. | 
| | | | 
| STMAP2 {| CORAL | Writes a storage map if the MAP option is specified. | 
| l i | 
{| STTEST+ | PHAZ15 | Calis RDTST to process replacement statements. | 
| | | ; | 
| SUBADD+ | PHAZ15 | Generates the text to add the terms in a suoscript computation. | 
| | | ‘ | 
| SUBMLT+ | PHAZ15 | Generates the text to multiply the first term in a_ subscript | 
| | | computation by its associated length factor, or, in the case of | 
| | | variable dimension, to multiply the nth dimension by length. | 
| | | { 
| SUBSCR+ | PHAZ15 | Determines if a subscript text entry in the pushdown table | 
| | | should be entered into pnase 15 text, and calls’ subroutine | 
| | | GENER to output the text entry when appropriate. | 
| { { | 
| SWITCH+ | PHAZ15 | Inverts the order of the operands supplied to it. | 
| | | | 
| TESTBN | STALL | Tests the mode and displacement of a variable to determine | 
| | | whether or not a boundary violation exists. | 
| | | | 
| TESTWD | CORAL | Determines whether or not a given variable is to be processed | 
| | | by subroutine VARA. | 
| | | | 
| TXTLAB | PHAZ15 | Processes statement number text entries for subroutine GENER; | 
| | | creates entries in RMAJOR. i 
| | | | 
| TXTREG | PHAZ15 | Processes standard phase 15 text entries for subroutine GENER | 
| | |] and makes RMAJOR entries. | 
| | | | 
| UNARY+ j PHAZ15 | Checks for negativeness in the triplet supplied to it, and | 
| j {| modifies the triplet (if negativeness is present) to optimize | 
| | | subsequent code generation. Also detects multiplication opera- | 
| | { tions and attempts to implement them by generating shift | 
| | | Operations. earn “Gf 
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Table 9. Phase 15 Subroutine Directory (Continued) 
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{| Assigns relative addresses to all variables in the dictionary | 
| except for variables in COMMON and/or EQUIVALENCE statements, | 
| external functions, nameiist names, and variables called by | 
| name and not by vaiue. | 
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| Inserts the appropriate function operator into phase 15 text | 
{| and builds the parameter list for the referenced subprograim in | 
| the adcon table and in text. | 
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Chart ii. 
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Common Expression Elimination (XPELIM) 
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Chart 12. Forward Movement (FORMOV) 
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*. OOMINATOR .*———————>* TO LPSEL * 
| *%-. OUTSIDE .* * * 
*#eLOOP «* KKRKEKRKREKRKEEKRKEE 
Feo at 
| * NO 
| Vv 
oe 1000 
D2 Be HEKKED FREER ERREEE 
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He o* *MOVE TEXT ENTRY * 
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Backward Movement (BACMOV) 
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Strength Reduction (REDUCE) 
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o*e 
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* CRITERIA * #eATORS.* | *#.ATORSe* 
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ote Vv o*e 
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o* Ke | * TFYPLOC * o* Be 
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| * AG ® * C3 * 
* * * * 
KERN RHKE 
y 
RHEL JOEREKEEKERE HEHEHE JARRE AKHKKERE 
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(Soa eee Pe ee ee Qe eg pet a ae ee 1 
| Process | Basic | Primary j Secondary 
}------------------ }~-~------------------- }-------------=-------- }---------------------- 
| Common {Subscript, arithmetic |Matching operand 2, {Matching operand 2, 

| Expression Jor logical operator; |operand 3, ana Joperand 3, and 

| Elimination [binary operator | operator Joperator with 

| (XPELIM) | | Jno intervening 

| | | | redefinitions 
}---~-------------- $o--2-~---------=--=--=- }----------------------}+----------=---------- 
| Forward {Arithmetic or logical |Operand 1 unused {Operand 1, operand 2, 
| Movement {operator jin the loop joperand 3 undefined 

j (FORMOV) | | | below the text item 

; Backward {Arithmetic or logical |Operand 2 and {Operand 1 not busy 

| Movement | Operator |Operand 3 undefined Jon exit from target; 

| (BACMOV) | jin the loop joperand 1 undefined 

| | | jelsewhere in the loop 
[-~-~~-~----------- Sepa anna REnDEnTEP SEEDED SEEDED DEERE IP SENEEEE Seeeenrar eee neaeere ee 
i Strength |Additive operator; J Interaction of inert [Function of absolute 

| Reduction Jinert variable | variable with additive|constants or stored 

{ (REDUCE) | jor multiplicative | constants 

| | | operator | 

Lae 5Ss-eooee ees rts neo On re oP ats ep pe eT UP a ee Da ha og cea pclae J 
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Table 11. P 
airapemmmecuen ars 2 
| Subroutine] 


ACCEPT 


ALLCOR 
BACMOV 
BAKT 


BASVAR 
BIZX 


BKDMP 
BKP 
BKPAS 
BLK 
BLS 
BLSDTA 
BSTRIP 


BSYONX 


CNT 


CXIMAG 
DISCHK 
FCLT50 


FOLLOW 
FORMOV 
FREE 

FWDPAS 


FWDPS1 


FWP 
GLOBAS 


GLOBS1 


ee eee EEE seme SESE EE ED TS ces SET Soe ORD eS EE GEESE SE SS SEE cee eS ee ES ee OD ee SE ES ee SS SD ED ED eee SE eee EE SS SE SS ee SR SS Oe SE SS cee Oe ee Sees gee Se ees se 


{ 
! 
I 
I 
! 
| 
I 
| 
1 
| 


hase 20 Subroutine Directory 


I punction i 
“ACCEPT =| Sari cre © tual cecepeunce (eae Gn yarigples vnicn arc condidetes leur 1ocst | 
register assignment. | 
Allocates main storage to temporaries when necessary during text updating. 
Controls backward movement. | 
Computes the loop number of each module block. ! 
Assigns eminence values to base variables, and sets up composite MVF and | 
MVS matrixes. | 
Computes the proper MVX setting for each variable in each bliock of the 
module. | 
Printing routine for full register assignment. 
Common block for local register assignment. ! 
Controls local register assignment. ! 
Common block for structural determination routines. 
Computes the total size of each block in the module. ! 
Block data for branching optimization. : 
Block data for branching optimization. ! 
Identifies forward target (if any) of a loop and sets up composite MVX 
Matrix. | 
Block data area for phase 20. | 
Processes imaginary parts of complex functions during local register ! 
assignment. | 
Performs a displacement check on a_e subscript text items during local | 
register assignment. | 
Performs special checks on text items whose function codes are less than 
50. | 
Determines if interfering block causes redefinition of a variable. ! 
Controls forward movement. ! 
Releases busy registers during overflow conditions (local assignment). 
Table-building routine for full register assignment. 
Determines if text operands are register .candidates prior to local 
register assignment. | 
Common block for local register assignment. | 
Assigns most active variables to registers across the loop. | 
Provides (if necessary) loads and stores for variables globally assigned 
outside the loop. | 
EERE (continued) 
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Table 11. 
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iSubscarine 
GTBASE 
HILOWS 
INDTRY 
INERT 
INVERT 
LOc 


LPSEL 


LYT 
MBRAN 


MRCLEN 


NORMIZ 
NPRFUN 
OPT 

PERTRY 


PRELUD 
PROP1 


REDUCE 
REG 
REGAS 
RELCOR 
SEARCH 
SEG4 
SETREG 
SETUP 


SHARE 


SPLRA 


SRPRIZ 


cr rr ce cr re cee ce crs ee cee ee ree ee eee ee ee ne ee Se ee ee SS eee es ee eS ee ES ee Ee ee SS oe ee eee ee ee EE Se ee SRD ee SE ee ED eee ee TS ee ee 
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hase 20 Subroutine Directory (Continued) 


a me ee cre ce ee eet ce cee ry em ce ce a ee rr ce cs se ee ee rs mr cre ee ee ee ee ee ae ee me ce es ee ee ee ree ee ee ee we a ee ee ee a 


Common block for global assignment. 

Gets a base register for operands of text items during text updating. 
Determines if an even-odd register pair is available for indexing. 
Determines if an inert variable is valid for the entire loop. 
Produces new inert text entries for strength reduction. 

Gets text pointers in a backward direction. 

Block data for register assignment. 


Controls sequencing of loops and passes control to text optimization and 
register assignment routines. 


Determines which module blocks can be reached via RX branch instructions. 
Controls alternation of the compare and test entry for strength reduction. 


Performs special checks on text items whose function codes are greater 
than 55. 


Builds type tables for use by strength reduction. 
Controls phase 20 printing. 

Common block for phase 20. 

Performs compile-time mode conversions. 


Determines if block under consideration has a branch which transfers out 
of the loop. 


Processes operand 1 of text item being processed by local register 
assignment. 


Controls strength reduction. 

Common block for register assignment. 

Controls full register assignment. 

Releases temporary main storage so it can be reused. 

Provides register loads upon entering the module. 

Computes size of prologues, epilogues, and entry code. 

Updates text items to reflect global register assignments. 

Performs initialization for each text item during local assignment. 


Determines if the register assigned to operand 2 or 3 can be assigned to 
operand 1 during local register assignment. 


Assigns registers during basic register assignment. 


Prints a flowchart indicating the structure of the module. 


ee es re Se eee cores Se ee Gee SS ee Se eee Se eee See Cee enw cee re ceemee cme OD ee eee OE ee Ee SD meee SE eee SEE ees CS eee SES eee ee OS ees eee es tes eee Gee ge ee ee ee ee eee ee es es ee es he ee ol 
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Table 11. Phase 20 Subroutine Directory (Continued) 


eo 
| Subroutine] 


STx 
STXATR 
SUBTRY 
TARGET 
TOPO 


TRNSFM 


TYPLOC 


XPELIM 


XPELOC 


XPLACE 
XSCAN 

YCHANG 
YPLACE 


ZCHANG 


Fe rs ee cae a Oe ne a RE ee ET eS a OE SS ED CD A ee ES SEE SS OS EE SS A ee ee a SE a 


| 
| 
| 
| 
| 
| 
| 
| 
{ 
| 
| 
| 
{ 
{ 
i 
| 
| 
| 
| I 
XCHANG =| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
iL 


Sets status information for operands and base addresses of text entries. 
Printing routine for basic register assignment. 

Common block for text updating. 

Controls text updating. 

Checks conditions for elimination during backward movement. 

Identifies the members of a loop and its back target. 

Computes the immediate back dominator of each block in the module. 


Performs special checks on text items whose function codes are in the 
range of 50 to 55 inclusive. 


Locates interactions of text entries for strength reduction. 
Determines stored constants for common expression elimination. 
Controls common expression elimination. 


Locates common text entries ina local block during common expression 
elimination. 


Performs manipulations for common expression elimination. 
Performs local block scan for common expression elimination. 
Determines stored constants for backward movement. 

Performs manipulations for backward movement. 

Determines stored constants for forward movement. 


Performs manipulations for forward movement. 
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Table 12. P 


 Simipemer cna. 4 
| Subroutine 


~ 
{ 
t 
' 
! 
| 
| 
| 
1 
-- —_ 


CLASIF 
DELTEX 
FILTEX 
GETDIC 
GETDIK 
GETSPC 
KORAN 
LORAN 
MODFIX 
MOV 
MOVTEX 
MOZ 
OBTAIN 
PARFIX 
PERFOR 
SUBACT 
SUBSUM 
WRITEX 


YSCAN 
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hase 20 Utility Subroutines 


Function | 


! 
t 
| 
| 
! 
{ 
! 
| 
| 
! 
1 
! 
t 
! 
! 
! 
I 
{ 
| 
! 
I 
| 
! 
! 
I 
{ 
' 
I 
| 
! 
! 
I 
! 
{ 
! 
! 
I 
| 
! 
! 
t 
| 
! 
! 
! 
| 
' 
| 
| 
| 
! 
! 
| 
! 
I 
I 
| 
t 
! 
I 
| 
! 
I 
! 
I 
! 
! 
| 
! 
| 
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t 
| 
| 
! 
I 
obs 


Examines composite vectors, or each local vector if necessary. 
Classifies operands of the current text entry. | 

Deletes the current text entry by rechaining. 

Fills text space according to the arguments. 

Gets space for temporaries. 

Gets space for constants. 

Gets space for new text item. 

Performs bit manipulation for text optimization. 

Updates composite MVS and MVF matrixes. 

Adjusts text entry for possible mode change. 

Common block for text optimization. 

Moves text entries by rechaining, and updates MVS and MVF vectors. 
Common block for text optimization. | 
Obtains next local block for processing. 

Changes parameter list to correspond to text replacements. 
Performs combination of eonstanes at compile time. 

Performs replacement of operands with equivalent values. 
Replaces, if possible, operand values with equivalent values. 
Printing routine for text optimization. 


Performs local block scan for backward movement. 


Performs local block scan for forward movement. 


1 
1 
! 
! 
I 
1 
' 
! 
I 
! 
! 
| 
| 
{ 
| 
I 
| 
| 
1 
I 
I 
| 
1 
| 
! 
| 
| 
' 
I 
I 
| 
| 
I 
| 
| 
! 
' 
| 
I 
| 
| 
! 
| 
{ 
i 
I 
| 
| 
! 
! 
| 
| 
I 
I 
| 
! 
! 
| 
| 
| 
| 
! 
! 
| 
{ 
I 
I 
| 
! 
| 
I 
| 
! 
| 
| 
! 
te 


Chart 21. 


INITIL 
HERE ALEREERERER 
* FROM * SEE TABLE 13 FOR A BRIEF 
* Fso * DESCRIPTION OF THE SUB-— 
* * ROUTINES OF PHASE 256 


REREEKARERRHHEEE 


COSHH SOSH MHSSESESH AHS HSOHSEHOHSSESSEHHSSHEHSSESEBESEH SBE ELOEEESESE OES ESECESESES 


v 
ot, 
B1 ke 
o* Be 
e*BLOCK DATA *- YES 
*#e SUBPROGRAM «* 
te o* 
Ke o* 
He ot 
* NO 


v 
RRERKC | RREHRAEERRE 


* LYT1 * 
Kk HH HE 
* RESERVE ——— 
* ADDRESS bed 


* CONSTANTS * 
ERK ER EEERERE EERE 





1530 


HHEKAGOER ARERR HE HREAAG ZRH HKRRERAE 
* NADOUT * * DATOUT * 
e— 8 EHH KH HK HE i Hh RK FE — KR EE 
>* PROCESS 4 PROCESS * 
* ADCON * * DATA * 
* TABLE * * STATEMENTS * 


RERERKLHEREEEHRAERE 


RHEEHCI RH REREEREE 
* * 
*ENTER CONSTANTS* 
>* INTO TEXT * 
* INFORMATION * 
* * 
Perr rrrrrerr errr 


v 
HHH RED 2 UHHH RHEE 
* * 
*RESERVE STORAGE* 
* FOR VARIABLES * 
* AND ARRAYS * 
* * 
EEE AER EE EERE EERE 


v 
o*e 
E2 #. 
o* Fe 
* ANY *e 
*.  NAMELIST o* 
*. TEXT o* 
Be ot 
He ot 





*® ANY *e 
Re FORMAT o* 
%e TEXT o* 





v 
1 o*e 
G2 Fe 
o* He 
«*SUBPROGRAM *. 
He BEING o* 
*%eCOMPILED e* 
He = 
He of 
* NO 
| 
Vv 
FETE FEE EE EE 
* ATTACH * 
ee ee ee ee ey 
* GENERATE * 


* MAIN PROGRAM * 
* ENTRY CODING #* 
HEE KEREEE EERE EERE 


A 


v 
HRHREEK OER RERERERE 


* NADOUT * 
HE — 4 — 8 E— HK — HE 
* PROCESS * 
* ADCON * 
* TABLE * 


REKKRAEKAKERKEEKEEEE 


>* BUILD * 


* NO | 
< 


>* TRANSLATE * 





. 

e 

e 

( . 

| - 

v . 

o*e Py 

H3 Fe ° 

o* He ° 

o* ANY *. NO e 
>*#ePHASE 215 DATA.*—— Py 
*e TEXT o* 1 . 
*e o* { . 

%e oF Vv Py 

* YES HHHNH 6 

¥22 * « 

* Al* «6 

* e 

* . 

° 

v ° 

HREREE SZRHHHMEKEEE e 
* DATOUT * e 
HK E— EH E— HEE e 
* PROCESS 7 : 
* DATA * | e 
* TEXT * ° 
KREKRERERKKRAERHEEE Vv e 
REEEE y 

#22 * «© 

* ALE 6 

He 6 

° 


Perce eeenesesetacacesesceeanesecesseocoreoses 


EERE EEE KEKE EE 


Vv 
HR KKKCZHEERE HERE EH 


* END * 
HK BF — HK HEE 
* COMPLETE * 


* PROCESSING * 
* OF MODULE * 
KEELE EEE ERE EEE 


| 
Vv 
HHH DZ RHAKERKER 
TO 
FSD 


OR 
* ORK 


HERRERA RERKEE 


HREEHE SHER KEERE 


* NLIST a 
HAH K—H— HHH HE 


* NAMELIST * 
* DICTIGNARIES ¥* 
ERE KKEK RHEE HERE 


HRAREERE SHEER EKER KE 


* FORMAT * 
HK KKH HK EE 


* FORMAT * 
* TEXT * 
REE RERERHEEELEEEE 


HREREGZ REN EERE RE 


* SUBR * 
EK H—H— K—H—H—HE 


eevee eevee eeree reese eeseereeeseeeeoeneeeoeseeeeeeeeeeseeeeeseeeeeseeeeeeneeeeeees 


>* GENERATE SU8B— *< 


* PROGRAM MAIN) #* 
* ENTRY CODING * 
URE EERE EEE EEK EH 


* 


Section 2: 
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Table 13. Phase 25 Subroutine Directory 


| Sreaeae maaan a eg ee ae eg he ee Ga ae tae ooe 1 
| Subroutine] Function | 
aki te NALS eer 4———~——~ +--+ + + +--+ | 
| ABSGEN? | Generates instructions for ABS, IABS, and DABS in-line functions. | 
| | | 
| ADMDGN+ | Generates instructions for the AMOD and DMOD in-line functions. | 
| | | 
| ATTACH {| Generates main program entry coding. | 
mn | : 
| BDATA | Initializes the masks and flags used by phase 25. | 
| | | 
| BITNFP1 | Generates instructions for the BITON, BITOFF, and BITFLP in-line func- | 
| j tions. 
| l | 
| BRANCH+ | Generates the instructions for all unconditional branching. | 
| | | 
| BRCOMB+ | Generates instructions for computed GO TO operations. | 
| { | 
| BRCOMP+ | Generates instructions for assigned GO TO operations. | 
| | | 
| BRLGL+ | Generates instructions for text entries whose operator is a relational | 
| | Operator operating upon two operands or one operand and zero. | 
| | | 
| BITBF+ |] Generates instructions for branch true and branch faise operations. | 
| i | 
| BXHCOM | Common data area used by phase 25. | 
| | | 
| CALLER | Generates calling sequences for CALLS (other than those to IHCFCOMH) and | 
| | function references. | 
| | 
| CGNDTA | Initializes the arrays used during code generation. | 
| | | 
| CMPLGNt | Generates instructions for the COMPL and LCOMPL in-line functions. i 
| | | 
| DATOUT | Processes phase 15 data text by entering into text information the initial | 
| | data values at the appropriate variable locations. | 
| | | 
| DBLGENt | Generates instructions for the DBLE in-line function. | 
| | | 
{| DCLIST | Produces a listing of the address constants of the object module. i 
| | | 
| DIMGEN+ | Generates instructions for the DIM and IDIM in-line functions. | 
| | | 
| DIVGEN+ | Generates instructions for all half- and full-word integer division. | 
| I | 
| END | Completes the processing of the object module. | 
| | | 
| ENTRY | Generates subprogram secondary entry coding. | 
| | | 
| EPILOG | Generates the epilogues associated with a subprogram and its secondary | 
| | entry points (if any). | 
| I | 
| FAZ25 | Common data area used by phase 25. | 
| | | 
| FLTGEN+ | Generates instructions for the FLOAT and DFLOAT in-line functions. | 
| H | 
| FNCALL | Generates the instructions. to store the result returned by a function | 
| | subprogram. | 
| | | 
| FORMAT | Translates FORMAT statements to a form acceptable to IHCFCOMH. | 
| I oe | 
| GOTOKK | Used by subroutine MAINGN to branch to the code generation subroutines. | 
Per ere ae 5 “Sea eal AD ete p tel eed a CEE ae I IO Ee ye RNP ce PR eo Oo oe ae NN ye ER er RE ES ON rt 4 
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IEKTLOAD 
IEKWAG?+ 
INITIA 


INITIL 


INTMPY+ 


IOSUB/ 
IOSUB2 


LABEL 


LBITTF+ 
LDADDR+ 
LDBGEN+ 
LGLNOT+ 
LISTER 
LYT1 


MAINGN/ 
MANGN2 


MINUS+ 
MOD241 
MXMNGN+ 


NADOUT 


NDORGN+ 
NLIST 


NTFXGN+ 


PACKER 


PLSGEN+ 


PROLOG 
RETURN 


SHFT2+ 
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hase 25 Subroutine Directory (Continued) 
Function 
Builds ESD, TXT, RLD, and loader END records. 
Generates the instructions to implement the ASSIGN statement. 
Interface between FSD and subroutine INITIL. 


Controls the construction of that portion of text information down to, but 
not including, text conversion. 


Generates instructions for all half- and full-word integer division. 


Generate calling sequences for calis to ITHCFCOMH. 


Processes statement numbers by entering the current value of the location 
counter into the address constant reserved for the statement number. 
Generates the instructions for the TBIT in-line function. 
Generates the instructions for all load address operations. 
Generates the instructions for all load byte operations. 
Generates the instructions for logical NOT operations. 

Produces a listing of the final compiler generated instructions. 


Reserves address constants for statement numbers. 


Control the text conversion process of Phase 25. 

Generates the instructions for all subtraction operations. 
Generates the instructions for the MOD24 in-line function. 
Generates the instructions for the MAX2 and MIN2 in-line functions. 


Enters the address 


information. 


constants developed during the compilation into text 


Generates the instructions for the AND and OR in-line functions. 
Builds the object-time namelist dictionaries. 


Generates the instructions for the INT, and HFIX in-line 


functions. 


IDINT, IFIX, 


Packs the various parts of each instruction produced during code genera- 
tion into a TXT record. 


Generates the instructions for all addition operations and for real 


multiplication and division operations. 
Generates prologues for subprograms and secondary entry points (if any). 
Processes the RETURN statement by generating a branch to the epilogue. 


Generates the instructions for all right- and left-shift operations. 


ST A A AAR a aN SE a 1 
Subroutine] 


fs es see ee omen etree ees Set cee tees Gece Soe cpm Sets Se ce cee eee me pe, cer ee tne come ee Se eee ema ee es re eee mre ee ems et ce cine cee es ee ee ee ee ee ee ee ee ee ee ee eee es 


(Continued) 


Table 13. 


Gyn yaa sy fas Mgt yy ge NSO BR ame gel geek an Spee te ge a VP Mee Ree pe go gag awe Se NV a eg LPS ean gs Aes ee © ee ee HS EMT 
| 


Subroutine 
+ ni oa das po ea ile amine 
SHFTRL1+ 


SIGNGN1 


STOPPR1t 


STRGEN1t 
SUBGEN+ 
SUBR 


TENTXT 


TSTSET+ 


UNRGEN*+ 


(oe ee cree re eee ce a ee ce eS SS Se a 


Phase 25 Subroutine Directory (Continued) 


Function 
Generates the instructions for the SHFTR and SHFTL in-iine functions. 


Generates the instructions for the SIGN, ISIGN, and DSIGN in-line 
functions. 


Generates character strings in calls to IHCFCOMH for STOP and PAUSE 
statements. 


Generates the instructions for all store operations. 
Generates the instructions for subscript text entries. 
Generates subprogram main entry coding. 


Controls the processing of END, RETURN, I/0, and ENTRY statements, 
statement numbers, and end of I/O list indicators. 


Generates the instructions to (1) compare two operands across a relational 
Operator, and (2) set operand 1 to either true or false depending upon the 
outcome of the comparison. 


Generates the instructions for unary minus operations (e.g., A=-B). 


a a ce ce ee em rue em a nt re mee ee ce ser me me ee es ee me ee ee ee ee ec a a rs ee ee ae ee cere cree ee me ere re ec ee ee ee i ee ee ee ee 
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Chart 23. Phase 30 (IEKP30) Overail Logic 


IEKP30 
HERE AZ ERE E HERES SEE TABLE 14 
* FROM * FOR A BRIEF 
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* * 
* * 
HHH EEE EH KIN 
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* * 
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e*¥NO. GREATER*. YES * MESSAGE * 
*%e THAN THAT .#———————>* AND ¥———__------—-+------ 
*. ALLOWED o* * LENGTH * 
He o* * * 
ke oF REKKHKEKEREKRERKKEEE 
* NO 
HREE | 
* * i 
* E3 *-—> 
* * 
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| 
{ Vv 
Vv ake 
HEKKKG IH HRHN KHER G5 Ke 
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KEANE HEE EE EEK Vv ee of 
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( HHEE | 
Vv 
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He eo* * * * * 
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| | 
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HASH Vv 
HERE JZ RR HEHE Vv 
* GET * HEKH ISH REE EH 
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* MESSAGE * * FSD * 
* POINTER TABLE * * * 
* ENTRY * HHL HE KR E HE 
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Table 14. Phase 30 Subroutine Directory 


De rear nae SS a eg rr tr ee OMe a ey ete ee 1 
| Subroutine | Function | 
W—--+----+-} --- -- + + + 5 | 
| IEKP30 | Controls phase 30 processing. | 

| | 
| MSGWRT | Writes the error messages using the FSD. | 
foe a pape rt Pt ene Mn) A koe IR oN Pf OG tN RE nS Eel SO J 
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This appendix contains text and figures 
that describe and illustrate the major 
tables used and/or generated by the FORTRAN 
System Director and the compiler phases. 
The tables are discussed in the order in 
which they are generated or first used. In 
addition, table modifications resulting 
from the compilation process are explained, 
where appropriate, after the initial for- 
mats of the tables have been explained. 


COMMUNICATION TABLE (NPTR) 


The communication table (referred to as 
the NPTR table in the program listing), as 
a portion of the FORTRAN System Director, 
resides in main storage throughout’ the 
compilation. It is a central gathering 
area used to communicate necessary informa- 


tion among the various phases of the com- 
piler. 

Various fields in the communication 
table are examined by the phases of the 


compiler. The status of these fields de- 


termines: 


e Options 
grammer. 


Specified by the source pro- 


e Specific action to be taken by a phase. 


If the field in question is null, the 
option has not been specified or the action 
is not to be taken. If the field is not 
null, the option has been specified or the 
action is to be taken. Table 15 illus- 
trates the organization of the communi- 
cation table. 


CLASSIFICATION TABLES 


Classifying, 
tory subroutine 


a function of the prepara- 
(GETCD) of phase 10, 


APPENDIX A: TABLES 


each 
This code indi- 


involves the assignment of a code to 
type of source statement. 
cates to the DSPTCH subroutine which sub- 
routine (either keyword or arithemtic) is 
to continue the processing of that source 
statement. The following paragraph de- 
scribes the processing that occurs during 
classifying. The tables’ used in the 
classifying process are the keyword pointer 


table and the keyword table. They are 
illustrated in Tables 16 and 17, respec- 
tively. 

If the source statement has not been 


Signaled as arithmetic during source state- 
ment packing (see note), the classifying 
process determines the type of the source 
statement by comparing the first character 
of the packed source statement with each 
character in the keyword pointer table. If 
that first character corresponds to _ the 
initial character of any keyword, the key- 
word pointer table is then used to obtain a 
pointer to a location in the keyword table. 
This location is the first entry in the 
keyword table for the group of keywords 
beginning with the matched character. Ali 
characters of the source statement, up to 
the first delimiter, are then compared with 
that group of keywords. If a match 
results, the classification code associated 


with the matched entry is assigned to the 
source statement. If a match does not 
result, or if the first character of the 


source statement does not correspond to the 
first character of any of the keywords, tne 
source Statement is classified as an invali- 
id statement. 


Note: The packing process, which precedes 
classifying, marks a source statement as 
arithmetic if, in that statement, an equal 
Sign that is not bounded by parentheses is 
encountered. If the source statement has 
been marked as arithmetic, it is classified 
accordingly by the classifying process. 
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Table 15. Communication Table (NPTR(2,35)) 
i a a aa a oe ee ee ee 1 
| 1] |Pointer to i-character| 
1 | |symbol chain | 
}--+---~---------- +~--------~------------- { 


| 2|Previous |} Pointer to 2-character | 
| |Classification|symbol chain | 
{| |code (phase | | 
| $10) | | 


| 3}]Options (e.g.,|Pointer to 3-character | 
| |SOURCE, MAP) |symbol chain | 
}--+-------------- }----------------------- { 
{ 4] {Pointer to 4-character| 
i | {symbol chain | 
}--+----~--------- }~----~----------------- { 
| 5|Displacement |Pointer to 5-character | 
| [for temporary |Symbol chain | 
| |(phase 20) | | 


| 6|]Maximum line |Pointer to 6-character | 


| [count jsymbol chain | 
ease De ES tS ee eee hh ee ee | 
| 7|Reserved | Reserved | 
}-~}----------~~-- fanaa nnn nnn nnn nnn { 
{| 8|[Type of text {Reserved | 
| | (phase 10) | | 
faa pea ee Pe oe { 
| 9jPointer to |Pointer to last avail- | 
| Jnext available]Jabie phase 10 text | 
| {phase 10 text |entry | 
{| fentry | | 
}--}~-------------- 4_—~---~~--~~~---------- : 
]10] Name of routine | 
| | (subprogram/main program) | 
}--+----~--------- qao----------2----------- : 
{11 |, Phase switch |Trace switch | 
}~~}---~----------4--------~----—--------- 1 

| 

| 


13|GETCD ‘END' 
{card indicator 


{j14] Pointer to |Pointer to 4-byte | 


| |parameters [constant chain | 

|--4-~~~--~~--~---}---—- —----------- = 1 

{15]Addr. const. |Pointer to 8-byte con- | 

| |entry number |stant chain 

|16| Page count | Pointer to 16-byte con-| 
| | {stant chain | 
i I a a a ee ae ee ote 4 


j17|{Current line |Pointer to statement | 


| |count jnumber chain | 
[18] Reserved }1,34 copied here by| 
{ | [phase 20 | 
Een (ety ar nya aE a a sa eh Oe J 


(Continued) 
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Table 15. Communication Table (NPTR(2,35)) 
(Continued) 
(215 ee Wee ee ee, 
{19 |Reserved [2,34 copied here by| 
| | jphase 20 | 
amp nn fn neni { 
|20|Reserved | Reserved | 
pan panne nnn fn nn enn nnn nae 1 
|21|Reserved | Pointer to common | 
1 ft jaddress constants | 
}~-+-------------- }~---------------------- { 
}22|Pointer to |Next available error | 
{| |dictionary |table entry | 
| fJentry for | | 
{| |IBcom | | 
Soe Osan See ae cere amass 4 


|23]External func-|Pointer to end of 
{| jtion or CALL |statement number chain | 
| 


Jindicator | | 
Cepeda ee aa ea eh cl a ce ieee: | 
]24|Pointer to in-|Optimization switch | 
| |ilaine function | | 
| [storage | | 
=-}-------------- {~---------~---~--~-----| 
[25] {Pointer to common chain| 
}--+-~---—-------- }~---------------------- { 
|26|Reserved |Pointer to equivalence| 
{ | |chain i 
NS a ein haa te | 
| 27|Pointer to jPointer to data text | 
{ |iiteral con- |chain | 
| [stant chain | | 
{28| Instruction [Pointer to normal text | 
} |count | chain | 
| 29|]Pointer to jPointer to next avail- | 
| |branch table fable information table | 
{ |chain jentry | 
~-}--------------}--------~--~----------- { 
{30| BLOCK DATA {Pointer to end of | 
| |subprogram | information table | 
| |switch | | 
| 31|FUNCTION SUB- |SUBROUTINE SUBPROGRAM | 
| |PROGRAM switch|switch | 
Na ice a NO as ee Oh Sa | 


{32]Pointer to |Pointer to format text | 
| |namelist text |chain | 
| |chain | | 


|33]Size of con- 
{ [stants 


t--+ 
{34|Adcon table 
| |number 


Table 16. Keyword Pointer Table 


(oes Tt Poet ee 1 
| Character | Number | Displacement? | 
| (1 word) |} (1 word) | (1 word) | 
-~----------- }-----------}----------------] 
| A 1 | 0 | 
| | | | 
| B | 2 | 8 | 
| | | | 
| Cc I 5 | 30 | 
| | | | 
| D | 7 | 80 | 
| | | | 
| E | 5 | 159 | 
| | | | 
| 3 | 2 | 203 | 
| | | | 
| G | 1 | 221 | 
| | | | 
| H | 0 | 0 | 
| | | | 
| I | 5 | 227 | 
| | | | 
| J | 0 | 0 | 
| | | | 
| K | 0 i 0 | 
| | | | 
| L | 2 | 271 | 
| | | | 
| M | 1 | 297 | 
| | | 
| N | 2 | 303 | 
| | | 
| 0 | 0 | 0 | 
| | | | 
| P | 3 | 321 | 
| | | | 
| Q | 0 i 0 | 
I | | | 
| R | 5 | 342 | 
i 
| S | 3 | 384 | 
| | | | 
| T | 2 | 413 | 
I | | | 
| U | 0 | 0 | 
l | | | 
| Vv i 0 i 0 | 
| | | 
| W | 1 | 432 | 
| | | 
| Xx | 0 | 0 | 
| | | | 
| ¥ | 0 | 0 | 
| | | | 
| Z 0 | 0 i 
Seen ecenseae 1-----~-----1----_~----_-----] 


|*This field contains the number of key] 
| words beginning with the associated| 
{ character. | 
|?This field contains the displacement| 
| from the beginning of the key word table| 
| for the group of key words associated] 
{ with character. | 


Table 17. keyword Table 


fo Mo ete ‘a 
| 

| Length-11 | Key Word? |Code? | 
: — 
| 5 | ASSIGN | 1 | 
| | | | 
| 8 | BACKSPACE | 2 | 
| | | | 
| 8 | BLOCKDATA ;} 3 | 
| | | 
| 1u | COMPLEXFUNCTION ; 4 4 
| | | | 
| 7 | CONTINUE | a od 
| | | | 
| 6 | COMPLEX | 6 | 
{ { | | 
| 5 | COMMON | 7 | 
I | | 
| 3. =|CALL | 8 | 
| | | | 
| 22 | DOUBLEPRECISIONFUNCTION| 10 | 
| | | | 
| 14 | DOUBLEPRECISION j 41 | 
| | | | 
| 8 | DIMENSION ; 14 {| 
| | | | 
| 6 | DISPLAY } 15 | 
| | | | 
| 4 | DEBUG } 16 | 
| | | | 
| 3 | DATA iors 2 a | 
| | | 
| 1 | DO | 18 | 
| | | | 
| 10 | EQUIVALENCE ; 19 | 
| | | | 
| 7 | EXTERNAL j 20 | 
| | | | 
| 6 | ENDF ILE } 21 | 
| | | | 
| 4 j ENTRY } 22 | 
| | | | 
| 2 | END f. 232-4 
| | | | 
| 7 | FUNCTION {} 24 | 
| | | | 
| 5 | FORMAT L.. 25 
| | | | 
| 3 | GOTO | 27 | 
| i | | 
| 14 | INTEGERFUNCTION } 28 | 
| | | 
| 7 | IMPLICIT | 29 | 
| | | | 
| 6 | INTEGER { 30 | 
| | | | 
| 1 | IF (Logical) [. 3a. 4 
| | i | 
| 1 {| IF (Arithmetic) j 32 | 
| | 7 | | 
| 14 | LOGICALFUNCTION {| 33 | 
brsoceseesu 1 CS Ale Nap ener ped na EES =o Wey eee ar ETD [ eae 4 
(Continued) 
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Table 17. Keyword Table (Continued) 

haar were ecole ae te ee ee ee 7 
| Length-17]| Key Word? jCode? | 
}---------- $~------~--------------- }------ 1 
| | | | 
| 6 | LOGICAL | 35 | 
| I | | 
| 3 | MOVE {| 34 | 
| | { | 
| 7 | NAMELIST | 36 | 
1 | I | 
{ 5 | NORMAL | 37 | 
| | | | 
| 4 | PAUSE | 38 | 
| I | 
| 4 | PRINT { 39 | 
| | | l 
| 4 | PUNCH {| 40° | 
i I | | 
i 11 | REALFUNCTION i 41 | 
| | { | 
| 5 | REWIND } 42 | 
| | { i 
] 5 | RETURN { 43 | 
i | | | 
| 3 | READ { 44 | 
{ | | I 
| 3 | REAL ; 45 | 
| | | | 
| 9 | SUBROUTINE | 46 | 
| | I | 
| 8 | STRUCTURE |} 47 | 
| | l I 
| 3 | STOP {| 48 | 
i | | | 
| 7 | TRACEOFF | 49 | 
| | | | 
| 6 | TRACEON |} 50 | 
| | | 
| 4 | WRITE { 51 | 
}~--~-~--~---- Bea tsa a ae pet eee ee tose ose 4 
| 

1This part of the entry for each keyword| 


| 

| is one byte in length and contains af 
| value equal to the number of characters| 
| in that keyword minus one. | 
| | 
|2This part of the entry for each keyword| 
| contains an image of that keyword at one] 
| 

| 

| 

| 

| 


byte per character. | 


part of the entry for each keyword| 
is one byte in length and contains the| 
classification code for that keyword. | 


INFORMATION TABLE 


The information table (referred to as 
NDICT or NDICTX) is constructed by Phase 10 
and modified by subsequent phases. This 
table contains entries that describe the 
operands of the source module. The infor- 
mation table consists of five components: 
dictionary, statement number/array table, 
common table, literal table, and branch 
table. 
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INFORMATION TABLE CHAINS 


The information table is arranged as a 
number of chains. A chain is a group of 
related entries, each of which contains a 
pointer to another entry in the group. 
Each chain is associated with a component 
of the information table. 


The information table can contain the 
following chains: 
e A maximum of nine dictionary chains: 


one for each allowable FORTRAN variable 
length (1 through 6 characters) and one 
for each allowable FORTRAN constant 
Size (4, 8, or 16 bytes). Each dic- 
tionary chain for variables contains 
entries that describe variables of the 
same length. Each dictionary chain for 
constants contains entries that de- 
scribe constants of the same size. 

chain for 


e One statement number/array 


entries that describe statement num- 
bers. 
e Two common table chains: one for 


entries describing common blocks and 
their associated variables, and one for 
entries describing equivalence groups 
and their associated variables. 


e One literal table chain for entries 
that describe literal constants used as 
arguments in CALL statements. 


e One branch table chain composed of 
entries for statement numbers appearing 
in computed GO TO statements. 


Entries describing the various operands 
of the source module are developed by Phase 
10 and placed into the information table in 
the order in which the operands are encoun- 
tered during the processing of the source 
module. For this reason, a particular 
chain's entries may be scattered throughout 
the information table and entries describ- 
ing different types of operands may occupy 
contiguous locations within the information 
table. Figure 12 illustrates this concept. 


CHAIN CONSTRUCTION 


The construction of a chain requires (1) 
initialization of the chain, and (2) point- 
er manipulation. Chain initialization is a 
two step process: 


1. The first 
(e.g., an entry describing a 
of length one) is placed 
information table at the next 
ble Location. 


entry of a particular type 
variable 
into the 

availa- 
















Figure 12. Information Table Chains 


2. A pointer to this 
placed into the communication table 
entry (refer to the section, 
"Communication Table") reserved for 
the chain of which this first entry is 
a member. 


first entry is 


Subsequent entries are linked into the 
chain via pointer manipulation, as de- 
scribed in the following paragraphs. 


The communication table entry containing 
the pointer to the initial entry in the 
chain is examined and the first entry in 
the chain is obtained. The item that is to 
be entered is compared to the initial 
entry. If the two are equal, the item is 
not reentered; if unequal, the first entry 
in the chain is checked to see if it is 
also the last. (An entry is the last in a 
chain if its “chain" field is zero.) 


If the chain entry under consideration 
is the last in the chain, the new item is 
entered into the information table at the 
next available location, and a pointer to 
its location is placed into the chain field 
of the last chain entry. The new entry is 
thereby linked into the chain and becomes 
its last member. 


If the entry under consideration is not 
the last in the chain, the next entry is 
obtained by using its chain field. The 
item to be entered is compared to the entry 
that was obtained. If the two are equal, 
the item is not reentered: if unequal, the 
entry under consideration is checked to see 
if it is the last in the chain; etc. 


This process is continued until a com- 
parable entry is found or the end of the 
chain is found. If a comparable entry is 
found, the item is not re-entered. If the 
new item is not found in the chain, it is 
then linked into the chain. 


is ee ce cn Se me eer Se ek ee ee ee ms ces te sm ar cae me a ce ee ces ee ae ee rs ce eee me ae re re ne em ee ee se cr a re me ce ee ee ee ce ee ee ee ee ee ee re ee ee ee 
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OPERATION OF INFORMATION TABLE CHAINS 


describe the 
chains in the 


The following paragraphs 
operation of the various 
information table. 


Dictionary Chain Operation 


The operation of a dictionary chain is 
based upon “binary tree" notation. This 
notation provides two chains, high and low 
(with a common starting point), for the 
entries describing variables of the same 
length or constants of the same size. The 
common starting point is the first entry 
placed into the information table for a 
variable of a particular length or a_ con- 
Stant of a particular size. The following 
example illustrates the manner in which 
phase 10 employs the binary tree notation 
to construct a dictionary chain. 


Assume that the following variables 
appear in the source module in the order 
presented. 


D C E F A B 


When phase 10 encounters the variable D, 
it constructs a dictionary entry for it 
(refer to “Dictionary"), places this entry 
at the next available location in the 
information table, and records a pointer to 
that entry into the appropriate field of 
the communication table (refer to 
"Communication Table"). The entry for D is 
the common starting point for the chain of 
entries describing variables of length one. 
(When a dictionary entry is placed into the 
information table, both the high and low 
chain fields of that entry are zero.) 


When phase 10 encounters the variable C, 
it constructs a dictionary entry for it. 
Phase 10 then obtains the dictionary entry 
that is the common starting point and 
compares C to the variable in that entry. 
If the two are unequal, phase 10 determines 
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if the variable to be entered is 
than or less than the variable in the 
obtained entry. In this case, C is less 
than D in the collating sequence, and, 
therefore, phase 10 examines the low chain 
field of the obtained entry, which is that 
for D. This field is zero, and the end of 
the chain has been reached. Phase 10 
places the entry for C into the next 
available location in the information table 
and records a pointer to that entry in the 
low chain field of the dictionary entry for 


greater 


D. The entry for C is thereby linked into 
the chain. 

When the variable E is encountered, 
phase 10 carries out essentially the same 


procedure; however, because E is greater 
than D, phase 10 examines the high chain 
field of the entry for D. It is zero, 
which denotes the end of the chain. Phase 
10 therefore places’ the dictionary entry 
for E into the next available location in 
the information table and records a pointer 
to that entry in the high chain field of 
the dictionary entry for D. 


When the variable F is encountered, 
phase 10 constructs a dictionary entry for 
it and compares it to the variable in the 
entry that is the common starting point for 
the chain. Because E is greater than D, 
phase 10 examines the high chain field of 


the entry for D. This field is not zero 
and, hence, the end of the chain has not 
yet been reached. Phase 10 obtains the 


entry (for E) at the location pointea to by 
the non-zero chain field (of the entry for 
D) and compares F to the variabie in the 
obtained entry. The variable F is greater 
than the variable E. Therefore, phase 10 
examines the high chain field of the entry 


for E. This field is zero and the end of 
the chain has been reached. Phase 10 
places the entry for F into the next 


available location in the information table 
and records a pointer to that entry in the 
high chain field of the entry for E. 


Phase 10 carries out similar procedures 
to link the entries for the variables A and 
B into the chain. 


(If one of the comparisons made between 
a variable to be entered into the dictiona- 
ry and a variable in an entry already in 
the dictionary results in a match, the 
variabie has previously been entered and is 
not reentered. ) 


Figure 13 illustrates the manner in 
which the entries for the variables are 
chained after the entry for B has been 


linked into the chain. 


122 


(PSS RSS SSS Sa SSS FS == 1 
| | 
| | 
| ee a | 
| D Cc E F A B | 
| | 
| | 
|Note: The pointers from the top of one| 


|variable to the top of another variable| 
| represent high chain pointers. The | 
[pointers from the bottom of one variable| 
[to the bottom of another variable rep-| 
jresent low chain pointers. | 


Figure 13. Dictionary Chain 


Statement Number Chain Operation 


The statement number chain constructed 
by phase 10 is linear; that is, each 
statement number entry (refer to "Statement 
Number/Array Table") is pointed to by the 
chain field of the previously constructed 
statement number entry. The first state- 
ment number entry is pointed to by a 
pointer in the communication table. 


To construct the statement number chain, 
phase 10 places the statement number entry 
constructed for the first statement number 


in the module into the next available 
location in the information table. It 
records a pointer to that entry in the 
appropriate field of the communication 
table. (When a Statement number entry is 
placed into the information table, its 
chain field is zero.) Phase 10 links all 


other statement number entries into the 
chain by scanning the previously construct- 
ed statement number entries (in the order 
in which they are chained) until the last 
entry is found. The last entry is denoted 
by a zero chain field. Phase 10 then 
places the new entry at the next available 
location in the information table and 
records a pointer to that entry in the zero 
chain field of the last entry in the chain. 
The new entry is thereby linked into the 
chain and becomes its last member. 
(Throughout the construction of the state- 
ment number chain, phase 10 makes compari- 
sons to insure that a statement number is 
only entered once.) 


Common Chain Operation 


The chain constructed by phase 10 for 
the common information appearing in the 
source module is bi-linear; that is, phase 
10 links together: 

1. The individual common block name 


entries (refer to “Common Table") that 
it develops for the common block names 
appearing in the moduie. 


2. The dictionary entries (refer to 
“Dictionary") that it develops for the 
variables appearing in a particular 
common block. (The dictionary entry 
for the first variable appearing ina 
common block is also pointed to by the 
common block name entry for the common 
block containing the variable.) 


To construct the common chain, phase 10 
places the common block name entry that it 
constructs for the first common block name 
appearing in the module at the next availa- 
ble location in the information table. It 
records a pointer to this entry in the 
appropriate field of the communication 
table. Phase 10 then obtains the first 
variable in the common block, constructs a 
dictionary entry for it, places the entry 
at the next available location in the 
information table, and records a pointer to 
that entry in the Pl field of the common 
block name entry for the common block 
containing the variable. Phase 10 obtains 
the next variable in the common block, 
constructs a dictionary entry for it, plac- 
es the entry in the information table, and 
records a pointer to that entry in the 
common chain field of the dictionary entry 
constructed for the variable encountered 
immediately prior to the variable under 
consideration. (This entry is found by 
Scanning the chain of dictionary entries 
for the variables in the common block until 
a zero common chain field is detected.) 
Phase 10 obtains the next variable in the 
common block, etc. 


When phase 10 encounters a second unique 
common block name, it constructS a common 
block name entry for it, places the entry 
in the information table, and records a 
pointer to that entry in the chain field of 
the last common block name entry, which is 
found by scanning the chain of such entries 
until a zero chain field is detected. 
Phase 10 then links the dictionary entries 
that it constructs for the variables 
appearing in the second common block into 
the chain in the previously described man- 
ner. 


If a common block name is repeated in 
the source module a number of times, phase 
10 constructs a common block name entry 
only for the first appearance. However, it 
does include as members of the common block 
the variables associated with the second 
and subsequent mentions of the common block 
name. Phase 10 constructs a dictionary 
entry for the first variable associated 
with the second mention of the common block 
Mame and places it into the information 
table. It then scans the chain of dic- 
tionary entries constructed for the varia- 
bles associated with the first mention of 
the common block name. When the last entry 
in the chain is found, it records in the 


common chain field of that entry a pointer 
to the dictionary entry for tne new varia- 
ble. Phase 10 links the dictionary entry 
it constructs for the second variable asso- 
ciated with the second mention of a common 
block name to the dictionary entry for the 


first variable associated with the secona 
mention of that name; etc. 
If a third mention of a particular 


common block name is encountered, phase 10 


processes the associated variables ina 
Similar manner. It links the dictionary 
entries constructed for these variables as 


extensions to the dictionary entries devei- 
oped for the variables associated with the 
second mention of the common block name. 


Equivalence Chain Operation 


The chain 
the equivalence 


constructed by phase 10 for 
information appearing in 


the source module is also bi-linear. Phase 
10 links together: 
1. The individual equivalence group 


entries (refer to “Common Table") that 
it constructs for the equivalence 
groups appearing in the module. 


2. The equivalence variable entries 
(refer to “Common Table") that it 
constructs for the variables appearing 


in a particular equivalence group. 
(The equivalence variable entry for 
the first variable appearing in an 


equivalence group is pointed to by the 
equivaience group entry for the group 
containing the variable.) 


The construction of the 
chain by phase 10 parallels its construc- 
tion of the common chain. It links the 
equivalence group entries in the same man- 
ner as it does common block name entries, 
and links equivalence variable entries in 
the same manner as the dictionary entries 
for the variables in a common block. 


equivalence 


Literal Constant Chain Operation 


Phase 10 constructs the literal constant 
chain in the same manner as it constructs 
the statement number chain. It records a 
pointer to the first literal constant entry 
(refer to "Literal Table") it enters in the 
information table in. the appropriate field 
of the communication table. For each other 
literal constant entry, phase 10 records a 
pointer to its location in the information 
table in the chain field of the previously 
developed literal constant entry, which is 
found by scanning the chain of such entries 
until a zero chain field is found. 
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Branch Table Chain Operation 


The phase 10 construction of the branch 
table chain parallels that of the statement 
number chain. It records a pointer to the 
first branch table entry (refer to "Branch 
Table") it places into the information 
table in the appropriate field of the 
communication table. For each other branch 
table entry, phase 10 records a pointer to 
its location in the information table in 
the chain field of the previously developed 
branch table entry. 


INFORMATION TABLE COMPONENTS 


The following text describes the con- 
tents of each component of the information 
table and presents figures illustrating the 
phase 10 formats of the entries of each 
components. Modifications made to these 
entries by subsequent phases of the compil- 
er are also illustrated in figure form. 


Dictionary 


The dictionary contains entries that 
describe the variables and constants of the 
source module. The information gathered 


for each variable or constant is derived 
from an analysis of the context in which 
the variable or constant is used in the 


source module. 


VARIABLE ENTRY FORMAT: The format of the 
dictionary entries constructed by phase 10 
for the variables of the source module is 
illustrated in Figure 14. 


[| Byte A usage field = ~~ (1 word)| 
[aow'chain field =SCSC*~C*C=C<CS:*‘ we | 
i pyee Bueigecisig. ° St wera 
i iighchaia giela a wee 
i Modevtypeticia °° S  eoras) | 
[pil field SSS. wor | 
i bytes Hsace Hicia were | 
| (Used by phase 15) | 
Paecd'by eeiceds. °°. tk woe 
euea by Biases) ae ee 
i coencnchain ficia. a wee 
| Name field SS™S~*~*~*~«:Cwo S| 
Figure 14, ‘rorsat of blcttontryenedy: cor 


Variable 
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Byte A Usage Field: This field is con- 
tained in a fuil word, the high-order three 
bytes of which are not’ used. This field 
indicates a portion of the characteristics 
of the variable for which the dictionary 
entry was created. The byte A usage field 





is divided into eight subfields, each of 
which is one bit long. The bits are 
numbered from 0 through 7. Figure 15 


indicates the function of each subfield in 
the byte A usage field. 


ee a ee caret ee yy 7 
| Subfield | Function i 
}-----~------ }----~----------------------- { 
| Bit 0 'on' | not used | 
}-~---------- }+--~------------------------ { 
| Bit 1 ‘on" | symbol used | 
}------------ }~--------------------------- { 
| Bit 2 ‘on' | variable is in common | 
}------------ }----~----------------------- { 
| Bit 3 ‘on' | variable is an array used| 
| | to contain an object-time| 
| | FORMAT statement. 
}-------~---- |---------------------------- { 
| Bit 4 ‘on' | variable is equated | 
}---------~-- }----~----------------------- { 
| Bit 5 ‘on' | variable has appeared in an] 
{ | equivalence group that has| 
| | been processed by STALL | 
| | (used by phase 15) | 
[------------ ---------------------------- 
| Bit 6 ‘ont | symbol is an external func-| 
| {| tion name | 
}----~------- ------------------~--------- { 
| Bit 7 ‘on' | not used | 
Sea ere Maca aan Oy ees ee Be J 
Figure 15. Function of Each Subfield in 


the Byte A Usage Field of a 
Dictionary Entry for a Variable 


Low Chain Field: The low chain field is 
used to maintain linkage between the var- 
ious entries in the chain. It contains 
either a pointer to an entry that collates 
lower in the colilating sequence or an 
indicator (zero), which indicates that 
entries in the chain that collate lower 
than itself have not yet been encountered. 


Byte B Usage Field: The byte B usage field 
is contained in a full word, the high-order 
three bytes of which are not used. This 
field indicates additional characteristics 
of the variable entered into the diction- 


ary. It is divided into eight subfields, 
each of which is one bit iong. The bits 
are numbered from 0 through 7. Figure 16 
illustrates the function of each subfield 


in the byte B usage field. 


High Chain Field: The high chain field is 
used to maintain linkage between the var- 
ious entries in the chain. It contains 
either a pointer to an entry that collates 
higher in the collating sequence or an 
indicator (zero), which indicates that 


entries in the chain that collate higher 


than itself have not yet been encountered. 
fotSe oo Ce a 1 
| Subfield | Function | 
}------------ }---------------------------- 

| Bit 0 ‘on’ | variable is “call by value"| 
| | parameter 

}------------ }---------------------------- 

{| Bit 1 ‘on' | variable is "call by name"| 
| | parameter | 
|-----~----~- }---------------------------- : 
| Bit 2 ‘on" | variable is used as an| 
| | argument | 
}------------ }--------------------=------- 

| Bit 3 ‘on' | variable is used in NAME-| 
| | LIST statement | 
}----~------- }-----~~--------------------- : 
| Bit 4 ‘on"* | variable nas appeared in a| 
| | previous DATA statement | 
| | (phase 15) | 
[------------ }------~--~------------------ 

| Bit 5 ‘ont | variable is used as a sub-| 
| | script | 
}------------ }---------------------------- { 
} Bit 6 ‘on" | variable is in common, or| 
| | in an equivalence group and| 
| | has been assigned a rela-| 
| | tive address (phase 15) | 
}---------—-- }------------------------—--- 

| Bit 7 ‘on' | variable appears in DATA| 
| | statement | 
eee ae eg eae eh Me Sek ah See J 
Figure 16. Function of Each Subfield in 


the Byte B Usage Field of a 
Dictionary Entry for a Variable 


Mode/Type Field: The mode/type field is 
divided into two subfields, each one word 
long. The first word (mode subfield) is 
used to indicate the mode of the variable 
(e.g., integer, real); the second word 
(type subfield) is used to indicate the 
type of the variable (e.g., array, external 
function). Both the mode and type are 
numeric quantities and correspond to the 
values stated in the mode and type tables 
(see Tables 18 and 19). 


Table 18. Operand Modes 

Per pe ee Pose eas ee 1 
| Mode of Operand | Internal | 
| | Representation | 
| | (in hexadecimal) | 
penne wan nna m nena fon mananan nnn { 
| Logical*1 | 2 | 
| Logical+*4 | 3 | 
| Integer*2 | 4 | 
| Integer | 5 | 
| Real*8 | 6 | 
{| Real*4 | 7 | 
| Compiex*16 | 8 | 
| Complex*8 | 9 | 
| Literal | A | 
| Statement number’ | B | 
| Hexadecimal | Cc | 
| Namelist | D | 
bese we ete SSeS eee x sss epee a Rea ony ee a ee J 


Table 19. Operand Types 

fot ee ee i ria 7 
| Type of Operand | Internal 

| | Representation | 
| | (in hexadecimal) | 
}--------------------- }-------------------- { 
| Scalar | 0 | 
|Dummy scalar | él | 
| Array | 2 | 
|Dummy array | 3 | 
|External function | 4 | 
| Constant | 5 | 
{Statement function | 6 | 
| Negative scalar | 8 | 
{Negative dummy scalar| 9 | 
|Negative array | A | 
|Negative dummy array | B | 
| (in text) | | 
| Dummy array | B | 
| (in dictionary) | | 
|Negative external | C | 
| function | | 
|Negative constant | D | 
|Negative statement | E | 
| function | | 
Meee oe es Be ee ea fey ee ae yer ae Pee ey oP J 


Pi Field: The Pi field contains either a 
pointer to the dimension information in the 
statement number/array table if the entry 
is for an array (i.e., a dimensioned 
variable), or a pointer to the text gener- 
ated for the statement function (SF) if the 
entry is for an SF name. If the entry is 
neither for the name of an array nor the 
name of a statement function, the field is 
zero. 


Common Chain Field: This field is used to 
maintain linkages between the variables in 
a common block. It contains a pointer to 
the dictionary entry for the next variable 
in the common block. (If the variable for 
which a dictionary entry is constructed is 
not in common, this fieid is not used.) 


Name Field: This field contains the name 
of the variable (right-justified) for which 
the dictionary entry was created. 


MODIFICATIONS TO DICTIONARY ENTRIES FOR 
VARIABLES: During compilation, certain 
fields of the dictionary entries for varia- 
bles may be modified. The following exam- 
ples illustrate the formats of dictionary 
entries for variables at various stages of 
phase 15 processing. Only changes are 
indicated; * stands for unchanged. 


Dictionary Entry for. Variable After Dic- 
tionary Sorting: The format of a diction- 
ary entry for a variable after the diction- 


ary has been sorted during STALL is illus- 
trated in Figure 17. 
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Pe Wore) | 
Veveed Gy soci) oe 
aaa aaa OE 
| Népehaig ica wee 
fe rE , Words) | 
aaa POE 
fg aren an ae eer rea ea 
a a EEG 
ea re 
pea ee eee ne ea 
ee re A aeaey 
SR a eed SO ly alae SE NE ata gE re eed ne ere eEY SNES SONS J 
Figure 17. Format of Dictionary Entry for 


Variable After Sorting 


Dictionary Entry for Variable After Common 
Block Processing: The format of a diction- 
ary entry for a variable after common block 
processing is illustrated in Figure 18. 


Ropero ate a eg ee ay Pe eT ee a Ne ee 1 
| * (1 word) | 
}-~-----~---~-~-------------------------— : 
| Freed by sorting (1 word) | 
bas 5 a oo ee ee eee 
| * (1 word) | 
}~---~----~-----~—~------~----~--~-------------- 
| New chain field (1 word) | 
Jaana oan 3 se tees 
| * (2 words) | 
p----~+---+-+--+----+~+-~+---+-+--+--+--+--+--+~+-+- 
Ls (1 word) | 
}~--~----~+---~--~-+~--~+~--+--.-+.--~--——-- 
| * (1 word) | 
pe 
| Displacement from start of (1 word) j 
| common block (if variable is | 
| in common) | 
}--—--~-—~---—--~---—-+~~-~+~---+---------~-- 
{| Pointer to common block name (1 word) | 
} entry for block containing | 
| variable | 
faa he Se eee eh Socata 
| * (1 word) | 
pene aa a a a an 
| * (2 words) | 
Segal Weep a NE a NT <n OE Reo alee Kner aS J 
Figure 18. Format of Dictionary Entry for 
Variable After Commom Block 


Processing 


Dictionary Entry for Variable After PHAZ15 
Processing: The format of a dictionary 


entry for a variable after PHAZ15 process- 
ing is illustrated in Figure 19. 
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| * (1 word) | 
}~---------~~------------~---------------- { 
| Freed by sorting (1 word) | 
}------------------~--~------~--~------~--- { 
| * (1 word) | 
boa a aS ee SS 

| New chain field (1 word) | 
be ee a ees See eee ee 

pe (2 words) | 
be Se ee ae eee 

| * (1 word) | 
Pale ee ee ee 

| Coordinate number for variable (1 word) | 
bagen ee ae ee ee eee 

{| Displacement from start of (1 word) | 
| common block (if variable is | 
| in common) | 
peo oe et a ee ee ens 

} Pointer to common block name (1 word) | 
| entry for block containing | 
| variable | 
pe Sa a a ee ea eae ee ee ooo 

| * (1 word) | 
ee a ee ee ee 

| * (2 words) | 
De ee i ee ee eas J 
Figure 19. Format of Dictionary Entry for 


Variable After PHAZ15 Process- 


ing 


Dictionary Entry for Variable After Rela- 


tive Address Assignment: The format of a 
dictionary entry for a variable after rela- 


tive address assignment is illustrated in 
Figure 20. 

(oo pee oa ee a ee ee ee re 1 
| * (1 word) | 
f--- 3 5  w -s + -+ 

| Pointer to entry containing (1 word) | 
| pointer to the address con- | 
| stant for the variable | 
p pee oe Soe a ee tent 

| * (1 word) | 
fe eee ee 

| New chain field (1 word) | 
bea ose eae ee Se ee eee aes 

| * (2 words) | 
poesia se ee ee 

| * (1 word) | 
peeereestieS ene eee ee eee ee 

| Coordinate number for variable (1 word) | 
bee cete eee eee a a eee 

| Displacement from associated (1 word) | 
| address constant | 
}-----------~---------~-----~------------- { 
| Pointer to common block name (1 word) | 
| entry for block containing | 
| variable | 
bee ee ee a 

| * (1 word) | 
ae Ss ee ee eee ee 

L + (2 words) | 
ME a Sh a eh Se re J 
Figure 20. Format of Dictionary Entry for 


a Variable After Relative 


Address Assignment 


CONSTANT ENTRY FORMAT: The format of the 
dictionary entries constructed by phase 10 
for the constants of the source module is 
illustrated in Figure 21. 


| Byte A usage field = (1 word)| 
eure ie, ea 
Pepe uncsceceicaas ee 
Wai gnciaes-caadecececeya aa wore 
Piaeyee aa eae 
Paeccua ee ay 
ee Ge cia Gee 
| phase 15) | 
VGeedypacseue a woeast 
couseaefiera’” =O Se ge 
Fighce 21, vormat. of Bletionary Entxy. for 
Constant 

The byte A usage, low chain, byte B 

usage, high chain, and mode/type fields of 


a dictionary entry for a constant contain 
the same information as a dictionary entry 
for a variable. 


Constant Field: The field contains the 
binary equivalent of the constant for which 
the dictionary entry was constructed. 


MODIFICATIONS TO DICTIONARY ENTRIES FOR 


CONSTANTS : During compilation, certain 
fieids of the dictionary entries for con- 
stants may be modified. The following 


examples illustrate the formats of diction- 
ary entries for constants at various stages 
of phase 15 processing. Only changes are 
indicated; * stands for unchanged. 


Dictionary Entry for Constant After Dic- 
tionary Sorting: diction- 





The format of a 
ary entry for a constant after the diction- 
ary has been sorted is illustrated in 
Figure 22. 


(Sn ere 1 
es (1 word) | 
| -------~------------~-------------------- { 
| Freed by sorting (1 word) | 
t a ea a Ss a Se eae Se ee Se ee 
| * (1 word) | 
bee eee ee eee ae ee eee 
{ New chain field (1 word) | 
Sea ee eh eg ee eee ee 
| * (2 words) | 
be ee ea eee 
| * (1 word) | 
beese ee eae Sees ese i ee eee 
| * (1 word) | 
Boe So Sea eae eee 
| * (1 word) | 
bees ae ee eee See eee Sa 
| * (4 words) | 
bales ee ee ae i ea J 
Figure 22. Format of Dictionary Entry for 


Constant After Sorting 


Dictionary Entry for Constant After PHAZ15 
Processing: The format of a dictionary 
entry for a constant after the processing 
of PHAZ15 is illustrated in Figure 23. 


an aaa am ann e mhad 3 oa anal 1 
| * (1 word) | 
Sei BS Se ee 4 
| Freed by sorting (1 word) | 
be a ee eee ee eee 
* (1 word) | 
}------+---+------~---~---+---~-------~--+--~-- 
| New chain field (1 word) | 
baat oe ee = a ee 
| * (2 words) | 
fra nr rr ern rrr 
| * (1 word) | 
boas eee 
| Coordinate number for constant (1 word) | 
}---~------------------~------------~+----- 
bo (1 word) | 
| aii i i e+ 
| * (4 words) | 
Ee a or Pe ico Se =A NOY A a ao OR cn Sacra OR J 
Figure 23. Format of Dictionary for Con- 


Stant After PHAZ15 Processing 


Dictionary Entry for Constant After Rela- 


tive Address Assignment: The format of a 
dictionary entry for a constant after the 


relative address assignment processes is 
complete is iliustrated in Figure 24. 
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| Pointer to entry containing (1 word)| 


| pointer to the address con- | 
| stant for the constant | 
}—-----~------------~~-~+~~----~~---~+-~---- 
LE 1 WORD) | 
poset ae ee eee eee 
{| New chain field (1 WORD) | 
}-~---------------~-----~------+~~+----+~--~-- 
| * (2 words) | 
}-~----~~~-----------—-------+~----+~+----+---- 
| * (1 word) | 
pra +--+ +s 
| Coordinate number for constant (1 word) | 
}-~~-------------------------------------- { 
| Displacement from associated (1 word) | 
| address constant | 
}--~--~-----~-+--------+~----~+----~+.----~-=- 
| * (4 words) | 
Wk ar a 4 
Figure 24. Format of Dictionary Entry for 


Constant After Relative Address 
Assignment 


Statement Number/Array Table 


The statement number/ array table con- 
tains statement number entries, which de- 
scribe the statement numbers of the source 
module, and dimension entries, which de- 
scribe the arrays of the source module. 


STATEMENT NUMBER ENTRY FORMAT: The format 
of the statement number entries constructed 
by phase 10 is illustrated in Figure 25. 


| Byte A usage field (1 word) | 
(eee ea 
ROE Gcae Re TT! TPS Tae aeapay) 
inet. ea 
ne re ea oe 
Teele ee 
ici eee ee, 
ulea apace a ee 
usc cea a ee 
(cae 
(Cone ee 
eed ty phcces sega 
aaa PEE 
Gee en ora ee a ees ceae” ae 
Entry 
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Byte A Usage Field: This field is con- 
tained in a full word, the high-order three 
bytes of which are not’ used. This field 
indicates a portion of the characteristics 
of the statement number for which the entry 
was created. The bytes A usage field is 
divided into eight subfields, each of which 
is one bit long. The bits are numberea 
from 0 through 7. Figure 26 indicates the 
function of each subfield of this field. 


ay aa ee ne Be 1 
| Subfield j Function | 
[-----~----~- }~-------~----~-------------- 
| Bit O ‘on* | statement number defined | 
}----——-~--—~ fon n nnn nnn nnn nn nna 
| Bit 1 ‘on‘ | statement number referenced| 
[~---------~- fa - ++ ~~~ == 
| Bit 2 ‘on* | referenced in an ASSIGN | 
| | statement | 
}----~---—--- }---------------------------- : 
| Bit 3 | not used | 
}------------ }---———~-------——-~-------~~- { 
| Bit 4 ‘on" | statement number of a FOR-| 
| | MAT statement | 
}~---------—-  SGEmeigmaia eas es ORGS a oraaas 
| Bit 5 ‘on"* | statement number of a GO| 
| | TO, PAUSE, RETURN, STOP, or| 
| | DO statement | 
}------------ }~-~----~-—-~---------------- 1 
{| Bit 6 ‘on" | statement number used as an| 
| { argument | 
f---~~------- fannan nanan 
{| Bit 7 ‘on* | statement number is the| 
| | object of a branch | 
| ons neon pee ee Bon eek eee ee eee arene LOPS en Cree Nien ay J 
Figure 26. Function of Each Subfield in 
the Byte A Usage Field of a 
Statement Number Entry 
Chain Field: The chain field is used to 
maintain linkage between the various 


entries in the chain. It contains either a 
pointer to the next statement number entry 
in the chain or an indicator (zero), which 
indicates the end of the statement number 


chain. 
Pointer Field: This field contains a 
pointer to the text entry constructed by 


phase 10 for the associated statement num- 
ber. 


Byte B Usage Fieid: This field is con- 
tained in a full word, the high-order three 


bytes of which are not used. The byte B 
usage field indicates additional charac- 
teristics of the statement number for which 
the entry was constructed. The byte B 
usage field is divided into eight sub- 
fields, each of which is one bit long. The 
bits are numbered 0 through 7. Figure 27 
indicates the function of each subfield in 
the byte B usage field. 


statement number appears in| 
END or ERR parameter of| 
READ statement | 
Soca ete ee et eee ee 4 
statement number is used in| 
a computed GO TO statement | 
Ss See ee ee ee J 
Function of Each Subfield in 
the Byte B Usage Field of a 
Statement Number Entry 


Ae eS A a a 


(crea Pe ee ea ae 1 
| Subfieid | Function | 
}------------ }---------------------------- 
Bit 0 ‘on* | statement number is within| 
| a DO loop and is trans-| 
| ferred to from outside the| 
| range of the DO loop | 
------------ }----------------------------1 
Bit 1 ‘on* | compiler generated state-| 
| ment number | 
~----------- }----------------------------| 
| not used | 
~----------- $----------------------------| 
| 
| 
| 
4 
| 
| 
re 


Figure 27. 


Image Field: This field contains the 
binary representation of the statement nur 
per for which the entry was created. 


MODIFICATIONS TO STATEMENT NUMBER ENTRIES: 
During the processing of phases 15, 20, and 
25, each statement number entry created by 
phase 10 is updated with information that 
describes the text block associated with 
the statement number. Figure 28 illus- 
trates the format of a statement number 
entry after the processing of phases 15, 20 
and 25. Only changes are indicated; * 
stands for unchanged. The phase making the 
indicated change is specified within paren- 
theses. 


New Chain Field: The new chain field 
pointer to the entry for the statement 
number that is defined in the source module 
immediately after the statement number for 
which the statement number entry under 
consideration was constructed. (Phase 15 
modifies the phase 10 chain pointer when it 
rechains the statement number entries to 
correspond to the order in which statement 


numbers are defined in the source module.) 
This field is not modified by subsequent 
phases. 

Address Constant Pointer Field: The 


address constant pointer field (after phase 
25 processing) contains either: 


e An indication of a reserved register 
and a displacement, if branching opti- 
mization is being implemented and if 
the text block (associated with the 
statement number entry under 
consideration) can be branched to via 
an RX~-format branch instruction (refer 
to the phase 20, "Branching Optimi- 
zation"). 


® A pointer to the address constant re- 
served for the statement number (refer 


to phase 25, “ADCON Table Entry 

Reservation"). 
poseeheste ieee see one eee eee ese eee ea 
| * (1 word) | 
}----------------------------------------- { 
| New chain field (phase 15) (1 word) | 
baa SS ee ee ee eee ee 
| * (1 word) | 
| --------------------~-------------------- { 


| Address constant pointer field (1 word) | 
| (phase 20 or phase 25) | 


p--—+---—----- - + +--+ = 5 + 
| * (1 word) | 
be a it ee eee ee 
| * (1 word) | 
}-—~---~~-—----—-------------------~------ { 
| Loop number field (phase 20) (1 word) | 
}-----—---~~-----.------ +--+ —------+----~-- 
| Back dominator field (1 word) | 
| (phase 20) | 
ee eae eee eee ee ee ee ee 
| Forward connection field (1 word) | 
| (ILEAD) (phase 15) | 
beet ee a a eee ae 
| Backward connection field (1 word) | 
| (JLEAD) (phase 15) | 
bee aa ee ae Se ee eee 
| Block status field (phase 20) (1 word) | 
}-----~-----------+--+---------------+--------+ 
| Text pointer field (phase 15) (1 word) | 
biG eee ee ee ee 
| * (1 word) | 
Cg ee ee ee 4 
Figure 28. Format of Statement Number 
Entry After the Processing of 


Phases 15, 20, and 25 

Loop Number Field: The loop number field 
contains the number of the loop to which 
the text biock (associated with the state- 


ment number entry under consideration) 
belongs. This field is set up and used by 
phase 20. Just before the loop number is 


assigned, this field contains a depth num- 
ber. 


Back Dominator Field: The back dominator 
field contains a pointer to the statement 
number entry associated with the back domi- 
nator of the text block associated with the 
statement number entry under consideration. 
This field is set up and used by phase 20. 
Forward Connection Field (ILEAD): MThe for- 
ward connection field contains a pointer to 
the initial RMAJOR entry for the blocks to 
which the text biock associated with the 
statement number entry under consideration 
connects. This field is set up by phase 15 
and used by phase 20. 

Backward Connection Field (JLEAD): The 
backward connection field contains a point- 
er to the initial CMAJOR entry for the 
blocks that connect to the text block 


Appendix A: Tables 129 


associated with the statement number entry 
under consideration. This field is set up 
by phase 15 and used by phase 20. 


The block status field 
low-order 


Block Status Field: 
is contained in a full word, the 
three bytes of which are not used. This 
field indicates the status of the text 
block associated with the statement number 
entry under consideration. The block sta- 


tus field is divided into eight subfield, 
each of which is one bit long. The bits 
are numbered 25 through 32. Figure 29 


indicates the function of each subfield in 
the block status field. 


| 
| 
! 
! 
I 
| 
I 
| 
| 
| 
| 
| 
| 
| 
! 
| 
! 
| 
| 
| 
| 
| 
| 
! 
! 
I 
| 
~ 


fro o ono 


| Subfield Function 


| 
| 
| 
{ 
{ 
| 
| 
! 
! 
| 
| 
| 
| 
I 
{ 
| 
| 
| 
! 
I 
| 
| 
| 
| 
| 
| 
te 


used for various reasons| 
by the routines that] 
explore connections (e.g.,| 
the associated block has| 
previously been considered | 
in the search for the back| 
dominator of the block) | 
the associated block exits| 
from a loop | 


{ 
I 
| 
I 
I 
| 
| 
| 
! 
! 
{ 
| 
{ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
1 
| 
| 
! 
! 
oe 


the associate block is a| 
fork (i.e., it has two or| 
more forward connections) | 


the associated block is in| 
the current loop | 
the associated block has| 
been completely processed| 
along the complete- | 
optimized path | 
ge ee J 
the associated block is an| 
entry block 


eS a oe ee ae 


| 
| 
| 
| 
1 
| 
| 
I 
| 
| 
| 
| 
! 
| 
| 
I 
| 
| 
| 
I 
| 
| 
| 
| 
I 
| 
| 
= 


Function of Each Subfield in 
the Block Status Field 


Figure 29. 


Text Pointer Field: The text pointer fieid 
contains a pointer to the phase 15 text 
entry for the statement number with which 
the statement number entry under considera- 
tion is associated. This field is not used 
by phase 10; it is filled in by phase 15, 
and is unchanged by subsequent phases. 


DIMENSION ENTRY FORMAT: The format of the 
dimension entries constructed by phase 10 
is illustrated in Figure 30. 


Dimension Number Field: The dimension 
number field contains the number of dimen- 
sions (1 through 7) of the associated 
array. 
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Array Size Field: The array size field 
contains either the total size of the 


associated array or zero, if the array has 
variable dimensions. 


| Dimension number field (1 word) | 
foo an ee 
Maeepeiedicia a wordy 
oe aE ee 
[ elenene Gengemeicla 4 weal 
(esecona dimension factor tela’ 41 wore) | 
i gabeicainensien factor sidia (gordi) 
| Pouttt, dimension actor ficid: (1 word) 
(opirehcainension eactercieia - 41. vera) 
| sinthi dimension ¢2cror ficial gra) 
i Seventh dimension eaceor sicla™ cl. yore) 
‘palmer <6 seae eubseripe. car owcca) 
| ameter 
}~-------------~~------------------------- { 
eee ea aeRO one Sa 


Figure 30. Format of Dimension Entry 


The element length 


Element Length Field: 


field contains the length of each element 
(first dimension factor) in the associated 
array. 

Second Dimension Factor Field: The field 


contains either a pointer to the dictionary 
entry for the second dimension factor, 
which has a value of D1*L, or a pointer to 
the dictionary entry for the first sub- 
Script parameter used to dimension the 
associated‘array, if that array has varia- 
ble dimensions. 

Third Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the third dimension factor, which 
has a value of D1*D2*L, or a pointer to the 
second subscript parameter used to dimen- 
sion the associated array, if that array 
has variable dimensions. This field is not 
used if the associated array is has a 
Single dimension. 


Fourth Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the fourth dimension factor, 
which has a value of D1*D2*D3*L, ora 
pointer to the third subscript parameter 
used to dimension the associated array, if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than three dimensions. 


Fifth Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the fifth dimension factor, which 
has a value of D1*D2*D3*#D44tL, or a pointer 
to the dictionary entry for the fourth 
subscript parameter used to dimension the 
associated array, if that array has varia- 
ble dimensions. This field is not used if 


the associated array has fewer than four 
dimensions. 
Sixth Dimension Factor Field: This field 


contains either a pointer to the dictionary 
entry for the sixth dimension factor, which 
has a value of D1*D2*D3*D4*D5*L, or a 
pointer to the dictionary entry for the 
fifth subscript parameter used to dimension 
the associated array, if that array has 
variable dimensions. This field is not 
used if the associated array has fewer than 
five dimensions. 


Seventh Dimension Factor Field: This field 
contains either a pointer to the dictionary 
entry for the seventh dimension factor, 
Which has a value of D1*D2*D3*D4*D5*D6*L, 
or a pointer to the dictionary entry for 
the sixth subscript parameter used to 
dimension the associated array, if that 
array has variable dimensions. This field 
is not used if the associated array has 
fewer than six dimensions. 


Pointer To Last Subscript Parameter: This 
field contains a pointer to the dictionary 


entry for the seventh subscript parameter 
used to dimension the associated array, if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than seven dimensions. 


Common Table 


The common table contains: 1) common 
block name entries, which describe common 
blocks, 2) equivalence group entries, which 
describe equivalence groups, and 3) equiva- 
lence variable entries, which describe 
equivalence variables. 


COMMON BLOCK NAME ENTRY FORMAT : The format 
of the common block name entries construct- 
ed by phase 10 is illustrated in Figure 31. 


Character Number Field: The character num- 
ber field contains the number of characters 
in the common block name. 


Chain Field: The chain field is used to 
maintain linkage between the various common 
block name entries. It contains either a 
pointer to the next common block name entry 
Or an indicator (zero), which indicates 
that additional common blocks have not yet 
been encountered. 


Pi Field: The P1 field contains a 
to the dictionary entry for the 
variable in this common block. 


pointer 
first 


Name Field: The name field contains’ the 
name (right-justified) of the common block 
for which this common block name entry was 
constructed. 


{ Character number field (1 word) | 
Vehsinticig mea 
iieesegs gece 
207 eS 
Pacesetter ea 
ruscioeyenceeas ea 
Name eicags weedy 
Dneeageas eran 


Format of a Common Block Name 


Entry 


Figure 31. 


MODIFICATIONS TO COMMON BLOCK NAME ENTRIES: 
During compilation, certain fields of com- 
mon block name entries may be modified. 
Figure 32 illustrates the format of a 
common block name entry after common block 
processing by STALL, the first segment of 
phase 15. Only changes are indicated; * 
stands for unchanged. 


| * (1 word) | 
bossa ee a eee 

|* (1 word) | 
}~----~------------------------------=---- { 
| * (1 word) | 
fp Sos ee ee ee 

|* (1 word) | 
f wea SSS oe Se ee ea eS ee eee 

| * (1 word) | 
| ----—-----~~----------------——----------- { 
| Total size of common block (1 werd) | 
be ee 

\* (2 words) | 
|* (5 words) | 
ee Sa aN a a Prine rom en CNT IS el No OEE rE J 
Figure 32. Format of Common Block Name 


Entry After Common Block Proc- 
essing 


EQUIVALENCE GROUP ENTRY FORMAT: The format 
of the equivalence group entries construct- 
ed by phase 10 is iliustrated in Figure 33. 


Number Field: The number field contains 
the number of variables being equivalenced 
in this equivalence group. 
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Chain Field: The chain field is used to 
Maintain linkage between the various equiv- 
alence groups. If contains a pointer to 
the next equivalence group entry. 


| Number field (1 wordd| 
(euaineicia "wee 
[Not used SSOS™*~*~*~*S~”S:CSS. wor | 
(piricia =. = Sk wore 
Pigeised. Oe ieee 
| Osea by phdce 15° ~=~=C~SC*C*C*C*S*S | 
[Not used S™S™S~™~™~*C«T «word | 
Pigure: 13, formas Gicad equivalence -ceeup 


Entry 


P1 Field: The Pi field contains a pointer 
to the equivalence variable entry for the 
first variable in the equivalence group. 


MODIFICATIONS TO EQUIVALENCE GROUP ENTRIES: 
During compilation, certain fielas of 
equivalence group entries may be modified. 
Figure 34 illustrates the format of an 
equivalence group entry after equivalence 
processing by STALL, the first segment of 
phase 15. Only changes are indicated; * 
stands for unchanged. 


Co a re ee ere ee 1 
bt (1 word) | 
}-----~----------------------------------- : 
| * (1 word) | 
}---------~---+--++-+-----——--~+----~+--~----~-- 

| * (1 word) | 
}——--—-~-.-—-----~---+—~----~----~---.------- 

| * (1 word) | 
}-~------—-----~--~---~-~+~----------------- 

| (1 word) | 
}---~------------------------------------- 1 
| Pointer to the "“head" of (1 word) | 


| the equivalence group | 


SR ep Se eer eee eee 
| * (7 words) | 
luteioeeee] oe aoe eee J 
Figure 34. Format of Equivalence Group 


Entry After 
essing 


Equivalence Proc- 


EQUIVALENCE VARIABLE ENTRY FORMAT: The 
format of the equivalence variable entries 
constructed by phase 10 is illustrated in 
Figure 35. 


Offset Field: The offset field contains 


the displacement of this variable from the 
first element in the equivalence group. 
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Pi Field: The Pl field contains a pointer 
to the dictionary entry for this equiva- 
lence variable. 

pono Sesame ake eben eh anes ee eee See ees 

| Used by phase 15 (1 word) | 
ft Se SS ae a aa SS a a a 

| Offset field (1 word) | 
be eS ee eee 

| Not used (1 word) | 
bee ee ee ee ee a eee 

| Pi field (1 word) | 
}--~-~----~-~~-~~~--~----~------~-----~-—- 

| Not used (1 word) | 
aa ee 

| Chain field (1 word) | 
pra mn nnn nnn nnn nnn 1 
| Not used (7 words) | 
Le Sta Se a eas a ee a 4 
Figure 35. Format of Equivalence Variable 

Entry 


Chain Field: The chain fiela is used to 
maintain linkage between the various varia- 
bles in the equivalence group. It contains 
a pointer to the equivalence variable entry 
for the next variable in the equivalence 
group. 


MODIFICATIONS TO EQUIVALENCE VARIABLE 
ENTRIES: During compilation, certain 
fields of equivalence variable entries may 
be modified. Figure 36 illustrates the 
format of an equivalence variable entry 
after equivalence processing by STALL, the 
first segment of phase 15. Only changes 
are indicated; * stands for unchanged. 


| Null indicator = (1 word)| 
Poleplcenent of ccricbie. Sasmeeah| 
| from group "head" | 
a eee eS ee 
a Bo, 
eee a 
eu aacmomas ps5: 
(a 


{The null indicator indicates to the rela-| 
Jtive address assignment portion of phase] 
{15 that main storage has been previously| 
Jallocated to this variable. This implies| 
Jthat the variabie: (1) is also in common, | 
Jor (2) appears in more than one equiva-| 
|ience group. | 
biSi ooo ee oe ea ee a ee J 
Figure 36. Format of Equivalence Variable 
Entry After Equivalence Proc- 
essing 


Literal Table 


The literal table contains literal con- 
stant entries, which describe literal con- 
stants used as arguments in CALL state- 
ments, and literal data entries, which 
describe the literal data appearing in DATA 


statements. (Entries for literal data 
appearing in DATA statements are not 
chained. They are pointed to from data 
text.) 


LITERAL CONSTANT ENTRY FORMAT: The format 
of the literal constant entries constructed 
by phase 10 is illustrated in Figure 37. 


The length field contains 
(in bytes) of the literal con- 


Length Field: 
the length 


stant. 


Chain Field: The chain field is used to 
Maintain linkage between the various liter- 
al constant entries. It contains a pointer 
to the next literal constant entry. 


Literal Constant Field: The literal con- 
stant field contains the actual literal 
constant for which the entry was construct- 
ed. The field ranges from 1 to 255 words 
(1 character/word, left-justified) depend- 
ing on the size of the literal constant. 


| Length field (1 word) | 
juesdbyiphase ds. = wo | 
faoeusegs pecan 
sed by haces. aw 
a ey 
cr rs) 


Format of Literal eee 


Entry 


-Figure 37. 


MODIFICATIONS TO LITERAL CONSTANT ENTRIES: 
During compilation, certain fields of 
literal constant entries may be modified. 
Figure 38 illustrates the format of a 
literal constant entry after relative 
address assignment by CORAL, the third 
segment of phase 15. Only changes are 
indicated; * stands for unchanged. 


| Pointer to entry containing (1 word) | 
| pointer to the address con- | 
| stant for the literal constant | 


| Displacement from associated (1 word) | 
| address constant | 


pect ne re ere ae 
1. a eas ee 
i. an ees, 
Bigare 30: Format Of iitetal  concvant 

Entry After Relative Address 


Assignment 
LITERAL DATA ENTRY FORMAT: The format of 


the literal data entries constructed by 
phase 10 is illustrated in Figure 39. 


a a a rs sr a i i tt i ee re ee ee ee ee ee ee ee ee ee ee 


Figure 39. Format of Literal Data Entry 


Length Field: The length field contains 
the length (in bytes) of the literal data 
for which the entry was constructed. 


Literal Data Field: The literal data field 


contains the actual literal data. The 
field ranges from 1 to 255 words (1 
character/word, left-justified) depending 


on the size of the literal data. 


Branch Table 


The branch table contains initial branch 
table entries and standard branch table 
entries. An initial branch table entry is 
constructed by phase 10 upon encounter of 
each computed GO TO statement of the source 
moduie. Standard branch table entries are 
constructed by phase 10 for each statement 
number appearing in the computed GO TO 
statement. 


INITIAL BRANCH TABLE ENTRY FORMAT: The 
format of the initial branch table entries 
constructed by phase 10 is illustrated in 
Figure 40. 
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| Indicator field (1 word) | 
fc eee 
coo ee 
ciaineiaia SO wera 
Puecaseg. eee 
[eeteia === ~OSCS*C*~CS~CS 
used By-phacegs a we 
pee gecg) ie a oeasy| 
Figure 40. Format of Initial Branch Table 
Entry 


Indicator Field: The indicator field is 
non-zero for an initial branch table entry. 
This indicates that the entry is for 
compiler-generated statement number for the 
"fall-through" statement. (The fall- 
through statement is executed if the value 
of the control variable is larger than the 
number of statement numbers in the computed 
GO TO statement.) 


Chain Field: The chain field is used to 
maintain linkage between the various branch 
table entries. It contains a pointer to 
the next branch table entry. 


Pi Field: The Pl field contains a pointer 
to the statement number/array table entry 
for the statement number for the compiler- 


generated statement number for the fall- 
through statement. 
MODIFICATIONS TO INITIAL BRANCH TABLE 


ENTRIES: During compilation certain fields 
of initial branch table entries may be 
modified. Figure 41 illustrates the format 
of an initial branch table entry after the 


processing of phase 25 is complete. Only 
changes are indicated; * stanas for 
unchanged. 

STANDARD BRANCH TABLE ENTRY FORMAT: The 


format of the standard branch table entries 
constructed by phase 10 is illustrated in 
Figure 42. 


Indicator Field: This field is zero for 


standard branch table entries. 





Chain Field: This field is used to main- 
tain linkage between the various branch 
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table entries. It contains a pointer to 
the next branch table entry. 


Pil Field: The P1 field contains a pointer 
to the statement number/array table entry 
for the statement number (appearing in a 
computed GO TO statement) for which the 


Standard branch table entry was construct- 
ed. 

Og I ee ea LP et es ee TE 1 
i: (1 word) | 
bie ee eee ee eee 


| Pointer to address constant (1 word) | 
| reserved for fall-through | 
| statement number | 


aE 
ma 
fe ea 
Pate oe eee he ee ara 
(ome lseiwey adavess on @eeeencne gore) 


| associated with fall-through | 
| statement number | 


p--+--s—-s--- +--+ 2 see eae sue 
| * (6 words) | 
bie SeSe Se Se ea eee eta ee eee J 
Figure 41. Format of Initial Branch Table 
Entry After Phase 25 
Processing 
fa ee a ee ee eo ee ee ee 
| Indicator fieid (1 word) | 
| ~--~--—~-----~---~~----~---~--~--~-----~- { 
| Not used (1 word) | 
bees See Se Se ese eae se Sas eee 
| Not used (1 word) | 
bans aae beast See oe eS ee 
| Chain field (1 word) | 
pease oe ee he ese ee nes 
| Not used (1 word) | 
bss Sie a oes eS ee eee tee ee 
| Pi field (1 word) | 
}----------------------------------------- { 
| Used by phase 25 (1 word) | 
}-+~—-~-—--—+—--+------~--~--+—~---+----++-~+- 
| Not used (6 words) | 
a ge eet a ee ee cee J 
Figure 42. Format of Standard Branch Table 
Entry 
MODIFICATIONS TO STANDARD BRANCH TABLE 
ENTRIES: During compilation, certain 


fields of standard branch table entries may 
be modified. Figure 43 illustrates the 
format of a standard branch tabie entry 
after the processing of phase 25 is com- 
plete. Only changes are indicated; * 
stands for unchanged. 


CSR a ee ee ee ) 
] * (1 word) | 
}-------~--+--~--+---~--+----+~-+~+-~--+.-- 
| * (1 word) | 
}---------~--+---~--+-+-----~-----------+--- 
ks? (1 word) | 
p—-—-—~ +--+ -- + ++ 5-5 - == = = ++ = 
| * (1 word) | 
}——~-------+--~---~--+-+------------------- 
| * (1 word) | 
}--------------++------+--+------+---+--------- 
| * (1 word) | 
[------------~~---------~------------------- 
{ Relative address of statement (1 word) | 
j associated with this statement | 
| number l 
[~--~------------------------------—------. 
| * (6 words) | 
sere ges eg ee a en ee a at a Ta 4 
Figure 43. Format of Standard Branch Table 
Entry After Phase 25 
Processing 


SUBPROGRAM TABLE 


The subprogram table (referred to as 
IFUNT or IFUNTB) contains entries for the 
IBM supplied subprograms and in-line rou- 
tines. The subprograms reside on the FOR- 
TRAN system library (SYS1.FORTLIB), while 
the in-line routines are expanded at com- 
pile time. The subprogram table is used py 
phase 15 to establish subprogran/argument 
compatibility. That is, phase 15 changes 
subprogram names (if necessary) so that the 
referenced subprogram or in-iine routine is 
made to agree with the mode of the 
argument(s) to it. For example, if the 
FORTRAN programmer references the MOD in- 
line routine, and if the argument to be 
operated upon is of real mode, phase 15 


with a 
argument 


replaces the reference to MCD 
reference to AMOD to ensure 
comparability?. 


Each entry in the subprogram table (see 
Table 20) contains three fieids: usage (4 
bytes), mode (2 bytes), and name (6 bytes). 


For an in-line routine, the 
of the 


Usage Fieid: 
usage field contains an indication 


mode of the result returned from it (see 
Table 18). For a #subprogram, the usage 
field is initially zero. If a subprogram 


is referred to in the source module (either 
explicitly when the suoprogram referred to 
agrees with the mode of the argument to be 
Operated upon, or implicitly either when 
the subprogram referred to is changed to 
ensure compatibility or when exponentiation 
or complex inultiplication and adivision 
operation are converted to a function 
reference), the arithmetic translator sets 
on the high order pit of the usage field in 
the entry for that subprogram. The rela- 
tive address assignment portion of phase 15 
interrogates in the high-order bit in the 
usage field for each subprogram. If on, an 
address constant is reserved for the sub- 
program, and a pointer to that address 
constant is placed into the usage field of 
the entry for that subprogram. 


Mode Field: The 
indication 


mode field contains an 
of the mode of the arguments to 


the subprogram (see Table 18). 


Name Field: The name field contains the 
name of the subprogram, right-7justified. 


1This process is called automatic typing. 
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Table 20. Subprogram Table 


Fe ee Seances Tao en Me pe 1 
{ Index | Usage | Mode | Name | 
}~--------- $--------- }-~------- 4---------- { 
| 1 | | 8 | CDABS | 
| 2 | | 9 | CABS | 
| 3 | | 6 | DEXP | 
} 4 | [| 7 | EXP | 
| 5 | | 8 | CDEXP | 
| 6 | | 9 | CEXP | 
Poe EE faa 
SIN 
| 9 i | 8 | CDSIN | 
{ 10 | | 9 | CSIN | 
| 42 | | 7 [oes | 
| 13 | | 8 | CDCOS | 
} 14 | j 9 j ccos | 
| 15 | | 6 | DSORT | 
| 16 | [| 7 | SORT | 
| 17 | | 8 | CDSQRT | 
ee 
LOG 
| 20 | | 6 {| DLOG | 
| 21 | | 7 | ALOG | 
| 22 | | 8 {| CDLOG | 
| 23 | i 9 | CLOG J 
| 24 | | 0 | LOG10 | 
| 25 | | 6 | DLOG10 | 
| 26 | | 7 | ALOG10 | 
| 27 | | 8 | CDLG10 | 
| 28 | | 9 | CLOG10 | 
i 29 | | 6 | DATAN | 
| 30 | | 7 {| ATAN | 
| 31 | | 6 | DATAN2 | 
| 32 ] | 7 | ATAN2 | 
| 33 | ] 6 | DSINH | 
| 34 | | 7 | SINH | 
| 35 | | 6 { DCOSH | 
| 36 1 | 7 | COSH | 
| 37 | | 6 | DTANH i 
| 38 | | 7 | TANH | 
Pt ES Laat 
T. 
| 44 | | 6 { DCOTAN | 
| 42 | | 7 | COTAN | 
| 43 | | 6 | DARSIN | 
} 44 | | 7 | ARSIN | 
| 45 | | 6 | DARCOS | 
| 46 | | 7 | ARCOS | 
| us | | 9 [aR | 
E ay 
| 49 | | 6 | DERFC | 
| 5. | 6 | beam | 
| 52 | | 7 | GAMMA | 
| 53 | | 6 {| DLGAMA | 
| 54 | | 7 | ALGAMA | 
ee ee 
| 937 | | l | 
| 58 | | | | 
| 59 | | | | 
| 60 | | 5 | AMAXO | 
| 61 | | Oo | MAX | 
| 62 | | 5 | MAxo0O | 
cece Hs tet OM scenes cas £2 Seeks 4 


(Continued) 
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[Pe ce ee ces ere cee em eames eee cme eee eee Sem ee omens Gone eee OLD eS Se SoS em Stee ES SEES me ao co STONE Rot: Se SS ce iS SS NY SE NE SS SE CL ES NS SN NY GS NE ES RD ES SS SS SN mm eR SRE SRE meet Gee Se Se SEN Sone 


fm me cs i cnc cr me ee ae cee ee me sm cee me A ne ce Nm ce a a ce fen me af 


WWWWWWWONTNCOTOCOAN ADU LUNANDNNAUNANUAN UW ~I 


womuoaonnnu 


OMV DUAN AANAOIAANTAMOUWAT YS 


SNSUUN NSN NDUN NON DNOO US) 


pm On en nt 


FDXPD# 
FRXPR# 
FDXPI# 
FRXP1# 
FCDXI# 
FCXPI# 
CDDVD# 
CDVD# 
CDMPY# 
CMPY# 
MAX2# 
MIN2# 
DIM 
IDIM 
DMOD 
MCD 
AMOD 
DSIGN 
SIGN 
ISIGN 
DABS 
ABS 
IABS 
IDINT 
AINT 
INT 
HFIX 
IFIX 
DFLOAT 
FLOAT 
DBLE 
BITON 
BITOFF 
BITFLP 
AND 

OR 
COMPL 
MOD24 
LCOMPL 
SHFTL 
SHFTR 
TBIT 
LAND 
LOR 
LXOR 


ADDR 
SNGL 
REAL 
AIMAG 
DCMPLX 
CMPLX 
DCONJG 
CONJG 


TEXT OPTIMIZATION BIT TABLES 


There are eight major bit tables used 
extensively throughout text optimization. 
These tables (each four words or 128 bits 
in length) contain bits that are preset. 
Only the first 86 bit positions in each 
table are meaningful and each of these is 
associated with a particular text entry 
operator. The settings (on or off) given 
to these bits indicate either the validity 
of operand positions in a text entry with a 
particular operator or the candidacy of a 
text entry with a particular operator for 
text optimization procedures. 


Three of these tables, MVW, MVU, and MVV 
are tested by subroutine KORAN and indicate 
the validity of the operand positions in a 
text entry with a given operator. The MVW 
table indicates the validity of the operand 
1 position; the MVU table indicates the 
validity of the operand 2 position; and the 
MVV table indicates the validity of the 
operand 3 position. For exampie, if the 
bit in MVW that corresponds to a particular 
Operator is on, then the operand 1 position 
of a text entry having that operator con- 
tains a valid or actual operand. If the 
bit is off, the operand 1 position of the 
text entry does not contain an actual 
operand. (In the latter case, the operand 
1 position may still contain information 
that is pertinent to the text entry; howev- 
er, it does not contain an actual operand.) 


The remaining five tables, MFM, MBM, 
MXM, MSM, and MBRK are aliso testea py 
Suproutine KORAN and indicate the candidacy 
of a text entry with a particular operator 
for text optimization procedures. The MFM 
taple indicates whether or not text entries 
with a particular operator are tc be con- 
Sidered for forward movement; the MBM table 
indicates whether or not text entries with 
a particular operator are to be considerea 
for backward movement; the mXM table indi- 
cates whether or not text entries witn a 
particular operator are to pe considered 
for common expression elimination; the MSM 
table indicates whether or not text entries 
with a particular operator are to pe con- 
Sidered for strength reduction; and the MBR 
table indicates whether or not the operator 
is a branch. For example, if the bit in 
the MFM table that corresponds to a partic- 
ular operator is on, then text entries 
having that operator will be considered for 


forward movement; if the bit is off, they 
will not. 
The text optimization bit tables are 


illustrated in Table 21. In this table, 
the operator associated with each pit posi- 
tion in the pit tables is identified. The 
bits settings for each operator as they 
appear in the bit tabies is also shown. An 
x Signifies that the oit is on; a olank 
signifies that the bit is off. 
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Table 21. Text Optimization Bit Tables 





Bit Tables 





Bit Tables 
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eee 
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EXT x | Xx DIM ei Kp eK EX 
BG X Xx ee | Xx IDIM Se ee Vee ie ae ace Me | 
—~T 
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BNE {| one a MOD PEseseeraess o- 
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Ss owe Xo | DSIGN XxX LX x_{| x | the 
Xx X SIGN Mo KE Re PK ae 
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pox pM |X X ISIGN EG Re Kee 
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24 |BCOMP X ABS X | X x | x | X 
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( IABS ae | a eS 
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EM IDINT ee Ea xX | xX | Xx 
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28 |BA X INT x | xX MM NS 
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29 | BBT i ere a,” Xx _| i HFIX Kl X ake 
os ae rt. — aren & 
30 | BBF | xX | xX iFIX [x | x xX | X x | 
: om zi £ 
31 | LBIT X Xx Xe Ke le DFLT | xX | X : aE ae Xx 
32_|BGZ ! | x | to i FLT | X | X xX | X | X 
33 | BLZ X DBLE | x | x x | x x 
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34 | BNEZ ea BITON | x | x 
x | | = BITOFF | xX | X 
x BITFLP x | X 
Xx X | X ane 
| lt er | on ZESESS ara 
| |le2 | comet x | x x_| x 
|_| e3 | mopza ae eal 
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REGISTER ASSIGNMENT TABLES 


Table 23. Global Assignment Tables 





: a amas rare ee ee en ee ee ee 1 
The register assignment tables are a set {Name | Function JOrigin | 
of one-dimensional arrays used by the full = }----~--4------------------------- 4+------~- { 
register assignment routines of phase 20. {|MCOORD|Serves as an index to|Phase 15| 
There are three types of tables: local { {MVD, EMIN, RA, RAL, WABP, | | 
assignment tables (refer to Table 22), | {WA and WJ. | | 
global assignment tables (refer to Table | | | | 
23), and register usage tables. The reg- | MVD {Gives the location of the|Phase 15] 
ister usage tables are work tables used by | |dictionary entry for the| | 
the local and global assignment routines in | jvariable associated with| | 
the process of full register assignment. | Jthe given value of | | 
| | MCOORD. | | 
| | 
Register Use Table |EMIN |Indicates whether the | REGAS | 
| jvariable associated with| | 
The format of the register use tables, | Ja particular MCOORD value] | 
TRUSE and RUSE, are the same for the local | Jis eligible for glocal| | 
and global assignment routines. Each table | Jassignment. | | 
is sixteen words long. Words 1 through 11 | | | | 
represent general registers 1 through 11, [RA Jindicates the number of|GLOBAS | 
words 12, 14, and 16 represent floating | Jthe first register glob-| | 
point registers 2, 4 and 6, and words 13 | jJally assigned to the| | 
and 15 are unused. | Jvariable represented by| | 
| Jthe MCOORD value; pro-| | 
| |vides continuity in glob-]| | 
Table 22. Local Assignment Tables | jal assignment from inner| | 
[ooo oon on  - t------- 1 | jto outer loops. | | 
| Name | Function _ [Origin | | | | | 
-}----+---------------~----~-------}------- |RAL | Indicates the register|GLOBAS | 
{J {Serves as index to TXP, BVR,|FWDPAS | | {globally assigned to the| | 
| | BVRA, BVA. | | | |variabie represented by| 
j | | | {the MCOORD value. j | 
|TXP {Gives the storage location|FWDPAS | | | | 
| jof the text item associated| | |WA | Indicates the total|FWDPAS | 
| {with each value of J. | | | jactivity for the variable| | 
| | i | | {represented by the MCOORD]| | 
{BVR |Contains the MCOORD value|FWDPAS | | | value. Calculated by | | 
| jJassociated with operand 1 of | | | jadding 4. to the value| | 
| Jthe text item represented by| | | Jeach time a definition of | | 
| {J. | | | Jthe variable is encoun-|]| 
| | wt | | jtered and adding 3. tol | 
| BVRA| Indicates the register|BKPAS | | jthe value for a use of| | 
| | locally assigned to the| | | Jthe variable. | | 
| |quantity represented by J. | | | | | 
i: | | | |WABP |Indicates the activity of|FWDPAS | 
{BVA |Represents the activity|FWDPAS | | jbase variables. Calcu- | | 
| jwithin the block of the] | | Jlated in the same manner] | 
| jquantity represented by J;| | | Jas the WA table. | | 
| jalso contains indicator bits| | t--—-—_ 4—-~----—~—------~—-~-------~- 4-------- 
| {describing the quantity. | | 
| | | If the contents of TRUSE(i) and RUSE(i) 
jWIJ2 |Indicates whether a variable|FWDPAS | is equal to zero, then register i is 
| Jis eligible for local | | available for assignment. If the value 
| jassignment. Indexed via the| | contained in TRUSE(i) or RUSE(i) is between 
| |MCOORD values obtained from| { 2 and 128, inclusive, then the register i 
| | BVR. | | is assigned to the variable whose MCOORD 
-----+---------------------------- 1---—-——— 1 value is equal to the contents of TRUSE(i) 
j4This column indicates the name of the] or RUSE(i). If the contents of TRUSE(i) or 
| register assignment routine that ini-| RUSE(i) has a value between 252 and 255, 


| tially creates the particular table. 


| 2#ALthough WI is 
assignment table, 


distinctly a 


local| 
it is indexed by the| 


quantity MCOORD (which is used to index| 


the 


global assignment’ tables) 


local assignment 


index, J. 


| 
| 
| 
| than by the 
| 
L 


rather | 
table] 


register i is unavailable for assignment 
and is reserved for special use (see next 
paragraph). 


Registers 15 
use by reg- 
reserved, and 
execution of 


Register Use Considerations: 
and 14 are not available for 


ister assignment. They are 
used for branching during the 
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the object module resulting from the compi- 
lation. 


Register 13 is not available for use by 
register assignment. It is reserved, and 
used during the execution of the object 
module to contain the address of the save 
area set aside for the object module (refer 
to phase 25% "Initialization 
Instructions"). This register is also used 
to reference the adcon table. 


Register 12 is not available for use by 
register assignment. It is set aside to 
contain the starting address of the 
"Constants" portion of text information. 


Registers 11, 10, and 9 may or may not 
be available for use by register assignment 


Their use depends upon the number of 
required reserved registers. (Refer to 
phase 20, “Branching Optimization"). 


NAME LIST DICTIONARIES 


Namelist dictionaries are developed by 


phase 25 for the NAMELIST Statements 
appearing in the source module. These 
dictionaries provide IHCFCOMH with the 
information required to implement 


READ/WRITE statements uSing NAMELISTs. The 
namelist dictionary constructed by phase 25 
from the phase 10 namelist text representa- 
tion of each NAMELIST statement contains an 
entry for the namelist name and entries for 
the variables and arrays associated with 
that name. 


NAMELIST NAME ENTRY FORMAT: The format of 
the entry constructed for the namelist name 
is illustrated in Figure 44. 


Figure 44. Format of Namelist Name aoe 
Name Field: The name field contains the 
namelist name, right-justified, with lead- 
ing blanks. 


NAMELIST VARIABLE ENTRY FORMAT: The format 
of the entry constructed for a variable 
appearing in a NAMELIST statement is illus- 
trated in Figure 45. 


| Name field (2 words) | 
| Address field (1 word) | 
Se ea ead ae acc Re | ain Ansaimanie® | 
| Item Type Hl Mode | Not used | 
| field | field | (2 bytes) | 
{| (1 byte) | (1 byte) | | 
boos pled cena ee eae i ee ates J 
Figure 45. Format of Namelist Variable 


Entry 
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Name Field: The name field contains the 
name of the variable, right-justified, with 
leading blanks. 


Address Field: The address field contains 
the relative address of the variable. 


Item Type Field: This field is zero for a 


variable. 


Mode Field: The mode field contains the 


mode of the variable. 


NAMELIST ARRAY ENTRY FORMAT: The format of 
the entry constructed for an array appear- 


ing in a NAMELIST statement is illustrated 
in Figure 46. 
(eS ee See Se ee a 
| Name field (2 words) | 
}---------------------------------~------- { 
| Address field (1 word) | 
pram naan oS EE eee 
| Item Type] Mode | Number of jElement | 
| field | field {| dimensions|length | 
| | | field {field | 
| (1 byte) | @ pyre) | (1 byte) ie byte) | 
f------~--- }-~---~---1__~--~-----1-------- 
| Indicator] First adipose | 
| field | factor field | 
} (1 byte) | (3 bytes) | 
}~------~-- }-~----------~-------~--------- { 
{ Not used | Second dimension | 
| | factor field | 
| (1 byte) | (3 bytes) | 
}-------~—- }----------------~------------- { 
| Not used | Third dimension 
| | factor field | 
| (1 byte) | (3 bytes) | 
}---------- ge se ae a a ae 
Etc. (refer to "Dimension Entry Format") | 


Figure 46. Format of Namelist Array Entry 


name field contains the 
right-justified, with 


Name Field: The 
name of the array, 
leading blanks. 


Address Field: The address field contains 
the relative address of the beginning of 
the array. 


Item Type Field: This field is non-zero 


for an array. 


Mode Field: This field contains the mode 
of the elements of the array. 
Number of Dimensions Field: This field 


contains the number of dimensions (1 
through 7) of the associated array. 


Element Length Field: The element length 
field contains the length of each element 


in the associated array. 


Indicator Field: This field is zero if the 
associated array has variable dimensions; 
otherwise, it is non-zero. 


First Dimension Factor Fieid: If the asso- 
ciated array does not have variable dimen- 
sions, this field contains the totai size 
of the array. If the array has variable 
dimensions, this field contains the _ rela- 
tive address of first subscript parameter 
used to dimension the array. 


Second Dimension Factor Field: If the 
associated array does not have variable 
dimensions, this field contains the loca- 
tion of the second dimension factor (D1*L). 
If the array has variable dimensions, this 
field contains the relative address of the 
second subscript parameter used to dimen- 
Sion the array. 


Third Dimension Factor Field: If the asso- 
ciated array does not have variable dimen- 
sions, this field contains the location of 
the third dimension factor (D1*D2*L). If 
the array has variable dimensions, this 
field contains the relative address of the 
third subscript parameter used to dimension 
the array. 


DIAGNOSTIC MESSAGE TABLES 


There are two major diagnostic tables 
associated with error message processing by 
phase 30: the error table and the message 
pointer table. 


ERROR TABLE 


The error table is constructed by phases 
10 and i5. As source statement errors are 
encountered by these phases, corresponding 
entries are made to the errcr table. Each 
error table entry consists of 2 one-word 
fields. The first field contains either an 
internal statement number, if the entry is 
for a statement that is in error, a dic- 
tionary pointer, if the entry is fora 
Symbol that is in error (e.g., a variable 
that is incorrectly used in an EQUIVALENCE 
statement), or a statement number, if the 
entry is for a non-defined statement num- 
ber; the second field contains the message 
number associated with the particular 
error. The message numbers that can appear 
in the error table are those associated 
with messages of error code levels 4 and 8 
(refer to the publication IBM System/360 


Operating System: FORTRAN IV Programmer's 
Guide). 


MESSAGE POINTER TABLE 


The message pointer table contains an 
entry for each message number that may 
appear in an error table entry. Each entry 
in the message pointer table consists of a 
Single word. The high-order byte of the 
word contains the length of the message 
associated with the message number. The 
three low-order bytes contain a pointer to 
the text for the message associated with 
the message number. 
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Intermediate text is an internal rep- 
resentation of the source module from which 
the machine instructions of the object 
module are generated. The conversion from 
intermediate text to machine instructions 
requires information about variables, con- 
stants, arrays, Statement numbers, in-line 
functions, and subscripts. This informa- 
tion, derived from the source statements, 
is contained in the information table, and 


is referenced by the intermediate text. 
The information table supplements the 
intermediate text in the generation of 


machine instructions by phase 25. 


PHASE 10 INTERMEDIATE TEXT 

Phase 10 creates intermediate text (in 
operator-operand pair format) for use as 
input to subsequent phases of the compiler. 
There are five types of intermediate text 
produced by phase 10: 


e Normal text - the operator-operand pair 
representations of source statements 
other than DATA, NAMELIST, FORMAT, and 
Statement Functions (SF). 


e Data text - the operator operand pair 
representations of DATA statements and 
the initialization constants in expli- 
cit type statements. 


e Namelist text - the operator-operand 
pair representations of NAMELIST state- 
ments. 


e Format text - the internal 
tions of FORMAT statements. 


representa- 


e SF skeleton text - the operator-operand 
pair representations of statement func- 
tions using sequence numbers as oper- 
ands of the intermediate text entries. 
The sequence numbers replace the dummy 
arguments of the statement functions. 
This type of text is, in effect, a 
"skeleton" macro. 


The intermediate 
are comprised of individual text 
entries. Each intermediate text type is 
allocated unique sub-blocks of main stor- 
age. The sub-blocks that constitute an 
intermediate text area are obtained by 
phase 10, as needed, via requests to the 
FSD (see FORTRAN System Director, "Storage 
Distribution"). 


Note: 
tions 


text representa- 


Intermediate Text Chains 


Each intermediate text area 
sub-blocks aliocated to a particular type 
of text) is arranged as a chain, which 
links together (1) the text entries that 
are developed and placed into that area, 
and (2) in some cases, the intermediate 
text representation for individual state- 
ments. 


(i.e., the 


The normal text chain is a linear chain 
of normal text entries; that is each normal 
text entry iS pointed to by the previously 
developed normal text entry. 


The data text chain in bi-linear. This 
means that: 
1. The text entries that constitute the 


intermediate text representation of a 
DATA statement are linked by means of 
pointers. Each text entry for the 
statement is pointed to by the pre- 
viously developed text entry for the 


statement. 
2. The intermediate text representations 
of incGividual DATA statements are 


linked by means of pointers, each 
representation being pointed to by the 
previously developed representation. 
(A special chain address field within 
the first text entry developed for 
each DATA statement is reserved for 
this purpose.) 


The namelist text chain operates in the 
Same manner as the data text chain. 


The format text chain consists of link- 
ages between the individual intermediate 
text representation of FORMAT statements. 
The pointer field of the second text entry 
in the intermediate representation of a 
FORMAT statement points to the intermediate 
text representation of the next FORMAT 


statement. (The individual text entries 
comprising the intermediate text represen- 
tation of a FORMAT statement are not 


chained. ) 


The SF skeleton text chain is linear 
only in that each text entry developed for 
an operator-operand pair within a particu- 
lar statement function is pointed to by the 
previous text entry developed for that same 
statement function. The intermediate text 
representations for separate statement 
functions are not chained together. Howev- 
er, a skeleton can readily be obtained by 
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means of the pointer contained in the 
dictionary entry for the name of the state- 
ment function. 


Format of Intermediate Text Entry 


Those statements that undergo conversion 
from source representation to intermediate 
text representation are divided into 
operator-operand pairs, or text entries. 


Figure 47 illustrates the format of an 
intermediate text entry constructed by 
phase 10. 

fo -se ee ee 1 

| Adjective code field (1 word) | operator 
fermen ne wm { 

| Chain field (1 word) | 

are oe Pe Oe gag PN rr OUP ROSEN CTS OR | 

| Mode field (1 word) | 
}-----~~~----~---------—------—~- { 

{| Type field (1 word) | 

ia ie a ae ea eee 4 

| Pointer field (1 word) | operand 
al ea et A ee J 
Figure 47. Intermediate Text Entry Format 


Adjective Code Field: The adjective code 


field corresponds to the operator of the 
operator-operand pair. Operators are not 
entered into text entries in source form; 


they are converted to a numeric value as 
specified in the adjective code table (see 
Table 24). It is the numeric representa- 
tion of the source operator that actually 
is inserted into the text entry. Primary 
adjective codes (operators that define the 
nature of source statements) also have 
numeric values. 


Chain Field: The chain field is used to 
maintain linkage between intermediate text 
entries. It contains a pointer to the next 
text entry. 


Mode and Type Fields: The mode and type 
fields contain the mode and type of the 
operand of the text entry. Both items 


appear aS numeric quantities in a text 
entry and are obtained from the mode and 
type table (see Tables 18 and 19). 


Pointer Field: The pointer field contains 
a pointer to the information table entry 
for the operand of the operator-operand 
pair. However, if the operand is a dummy 
argument of a statement function, the 
pointer field contains a sequence number, 
which indicates the relative position of 
the argument in the argument list. 


Note: The text entries for FORMAT state- 
ments are not of the above form. FORMAT 
text entries consist of the characters of 
the FORMAT statement in source form packed 
into successive text entries. 
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Table 24. Adjective Codes 


ieee ac SS cm a aaa 1 
| Mnemonic | | 


|Code (in| (where | | 


jdecimal) |applicable) | Meaning | 
}-------- $----------- f-----~------=------- { 
| | | | 
| 1 | .NOT. | NOT | 
| | | | 
| 4 | .AND. | AND | 
| | | | 
| 5 | ) |Right arithmetic | 
| | j parenthesis | 
| | | | 
| 6 } «OR. {OR | 
| | | . | 
| 8 | = |Equal sign | 
| | | | 
| 9 |. | Comma | 
| | | | 
| 10 | + | Plus | 
| | | | 
| 11 ti |Minus | 
| | | | 
| 12 | * | Multiply i 
| | | | 
| 13 i 7 | Divide | 
| | | 
| 14 | ** |Exponentiation | 
| | | | 
| 15 | (£ jFunction parenthesis] 
| | | 
| 16 | -LE. |Less than or equal | 
| | | | 
| 17 {| -GE. {Greater than or | 
| | [equal | 
| | | | | 
| 18 {| .EQ. | Equal j 
| | | | 
| 19 {| .LT. {Less than | 
| | | | 
| 20 | .GT. |Greater than | 
| | | | 
| 21 | -NE. | Not equal | 
| | | 
| 22 | (s |Left subscript | 
| | j|parenthesis | 
| | | | 
| 25 | ¢ jLeft arithmetic | 
| | |parenthesis | 
| | | | 
| 26 | [End mark | 
| | | | 
| fal | |GOTO, and implied | 
| | | branches | 
| | | | 
} 193 | |BLOCK DATA | 
| | | | 
{| 205 | | DATA | 
| | | | 
| 208 | | SUBROUTINE, | 
| | | FUNCTION, or ENTRY | 
| I | | 
{| 209 | | FORMAT (text) | 
| | | 
} 210 | JEnd of I/O list | 
Latiasa sas Het ee ieee Setar ee te J 


(Continued) 


Table 24. Adjective Codes (Continued) 
pata: Pe ee en eS Pee ae hoe 1 
| Mnemonic | | 
{Code (in| (where | 
| decimal) |applicable) | Meaning 
proce mannan nnn fn nnn { 
j 211 i | CONTINUE | 
| | | i 
{ 213 | jObject time format | 
| | | variable | 
| | | | 
{| 214 | | BACKSPACE | 
| | | | 
{| 215 | | REWIND | 
| | | | 
| 216 | JEND FILE | 
l | | 
| 217 | {WRITE unformatted | 
{ | | | 
{ 218 | |READ unformatted | 
| | | | 
{| 219 | {WRITE formatted | 
| | | { 
J 220 | {READ formatted { 
| | | l 
{ 221 | |Beginning of I/0 | 
| | jlist | 
| | | i 
| 222 | LDF {Statement number j 
| l | definition | 
| | | 
} 223 | GLDF |Generated statement | 
{ | jnmumber definition | 
I | | | 
| 225 | |WRITE using NAMELIST| 
[ | | i 
| 226 | {READ using NAMELIST | 
! | | | 
j} 230 | {170 end-of-file | 
| | {parameter | 
| | | | 
| 231 | {I/O error paraneter | 
bese fie ae oe ee a oes cee ere 4 


(Continued) 


Table 24. Adjective Codes (Continued) 
Sepa scat cas os ee aa aa aaa 1 
{Mnemonic | | 
{Code (in] (where | | 
| decimal) japplicable) | Meaning | 
}-------- fo-------=--} ~~ =~ === 1 
| 232 | | BLANK | 
| | | | 
[: “233 | RET | RETURN | 
| | | | 
} 234 | STOP | STOP | 
| | | | 
| 235 | | PAUSE | 
| | | | 
| 238 | | ASSIGN | 
| [ | | 
} 240 | |Beginning of DO | 
| | | 
} 241 | jArithmetic | 
| | jassignment statement | 
| | | | 
} 242 {| NDOIF {End of DO 'IF'* | 
| | | 
| 243 | jArithmetic IF | 
| | | 
| 244 { |Relational IF { 
| | | | 
{| 246 | {CALL l 
| i | | 
| 247 { LIST |I7O0 or NAMELIST list] 
| | jitem | 
| i | i 
| 248 I | NAMELIST | 
| I | | 
| 249 | END | END | 
| | | | 
| 250 j |Computed GOTO | 
| | | 
{ 251 | JI/7O unit number | 
| | | 
} 252 | [FORMAT (statement | 
| | |numbers) | 
| | { | 
{| 253 | |NAMELIST name | 
PEt ae eee Sansa ee ee eye Seater a San er cient Arca J 
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Examples of Phase 10 Intermediate Text 


An example of each type of phase 10 text (normal, data, namelist, format, and SF 
skeleton) is presented below. For each type, a source language statement is first given. 
This is followed by the phase 10 text representation of that statement. 


The phase 10 normal text representation of the arithmetic statement 100 A=B+tcCc# BD 
/ E is illustrated in Figure 48. 





fee ee To ee ee hs, er en ee Ren ee re ame acta ea oi 7 
| Adjective | | | | | 
| Code | Chain | Mode | Type | Pointer | 
|----------------- --------------—- $-----~--------—-- fannn nnn n naan nn f---------------- { 
| Statement | | | | | 
| number | | Statement | | | 
definition | number i 0 | ——» 100 | 
p----—------------ $---------------- }---------------- { 

| Real | Scalart | ——> A | 

p-—------------—- ee aR {-----------~--~- : 

| Real | Scalart | —-~ B | 

$--~---—-------—-- +—-----------—-- f--------—--~--~— { 

| Real | Scalart | —~c | 

{----------------- $---------------- $---~--------~--- { 

| Real | Scalart | —-»D | 

Re aa a EARP oe a { 

| Real | Scalart | —©_E | 

| sig a Rc }~—-------------- { 

| To next normal | | | | 

| End mark? j text entry | 0 | 0 | ISN? 
t----------------- }---------------- }~--------------- { 

| 1 word | 1 word | 1 word | 

Bann sagen ee ne Ne Bey ee oe ee ee A penne ane eee Beet pa ct ake ED | 





| +Nonsubscripted variable. | 
| 2Operator of the special text entry that signals the end of the text representation | 
| of a source statement. | 
| 2Compiler generated sequence number used to identify each source statement. | 
L 


Figure 48. Phase 10 Normal Text 
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The phase 10 data___— text representation of the DATA statement DATA 
A, B/2.1,3HABC/,C,D/1.,1./7 is illustrated in Figure 49. 





pore en en ae T T Le Sey re 9 Sa aca a a 1 
| Adjective | | | | | 
| Code | Chain | Mode | Type | Pointer | 
+ foso aceon ans + == panna anne nasa }----~-~--------~ 
| | | | To text for | 
| | | | —* next DATA i 
| 0 | 0 | statement | 
{-----------~----- foa------===---~— }---------------- { 
| 0 | 0 | ISN | 
~~--------------- }---------------- $---------------- { 
| Real | Scalar | —.A | 
$--------~------~- {------—--------~ $o---=------ ~~ - { 
| Real | Scalar {FB | 
ee ee gaa {----------—--~--- $------~--------- { 
| Real | Constant j —* 2.1 ] 
}-----------—----- }---~-~---------- }----~=---------- 1 
| Literal | Constant | —-» 3HABC | 
t-~--------------- ----~-~-=--~---- $------~--------- 1 
| Real | Scalar Reema. aa © i 
$----~------------ }--~~—-~--~—~----- $oan--—---------- 1 
| Real | Scalar |—~*D | 
{----------------- $---------------- }---------------- : 
| Real | Constant | —.1. | 
{----------~-----~ {-----~--—--~~--- }---------------- 1 
| Real | Constant [ies | 
to-----~----=----- }-------~-------- }--~-----~------- : 
| 1 word | 1 word | 1 word | 
DS Se el eRe peep eaten apap meee et ES mae ay eee J 





Figure 49. Phase 10 Data Text 
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The phase 10 namelist text representation of the NAMELIST statement NAMELIST 
/NAME1/A,B,C/NAME2/D,E,F/NAME3/G where A and F are arrays is illustrated in Figure 50. 








nace a ace nana 5 Aa nal a ha Loe eg 1 cal ne ome marae ee a en 7 
| Adjective | | | | | 
| Code | Chain | Mode | Type | Pointer 
}-—--------------- }----------------- ennnnn nnn 2 a= oe a -------=--=---------- { 
| NAMELIST | | NAMELIST | 0 | ——» NAME1 | 
}----------------- $----------- }--------------------- { 
| 0 | 0 | To text for | 
{ | | ——» next NAMELIST 
| | | block | 
{----------------- }----------- }--------------------- { 
| Real | Array | —~> A | 
}----------------- $-------=--- }--------------------- { 
| Real | Scalar |——~ B | 
$----------------- $----------- }--------------------- { 
| Real | Scalar | —~C | 
$----------------- }----------- }~------~------------- { 
| NAMELIST | | NAMELIST i 0 | ——» NAME2 | 
}----------------- +----------- {--------------------- { 
| 0 | 0 | To text for 
| | | ——» next NAMELIST | 
| | | block 
}----------------- }----------- {--------------------- { 
| Real | Scalar | —~+D | 
}----------------- {----------- 4$--------------------- { 
| Real | Scalar | —* E | 
$----------------- $----------- $--------------------- : 
| Real | Array | ——> F | 
}--~-------------- }----------- }--------------------- { 
| NAMELIST | | NAMELIST | 0 | —— NAME3 i 
}----------------- ----------- }--------------------- : 
| 0 | 0 | To text for 
| | | ——» next NAMELIST | 
| | | statement t- 
+----------------- ----------- ~-------------------- { 
| Real | Scalar | —~*G | 
$----------------- }----------- {~--------------------- { 
| 1 word | 1 word | 1 word | 
i Seager Ea a ee nay ey ny A Wari bene enema Epa pales pele Meenas Reopen er et er DN J 





Figure 50. Phase 10 Namelist Text 
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The pha 


so oe a Tape re a ae foe ae rg Ge y (ae aa acer icaiad 
| Pointer | | | 
| Code | Chain | Mode | Type 
}----------------- {~---------------- }----------------- +---------- 
| Statement -| | | 
| number | | Statement | 
| definition | | number | 0 
$----------------- }---------- 
| | 
| | 
| 0 | 0 
}-~--------------- $---------- 
| 115% | 231 
fren nnn nnn e nnn $---———-~== 
| -3,' | ABC" 
f----~=~-—-------- $-—-------- 
| 1 word | 1 word 
doen ke eee ae ee oeree eae ae 





Figure 51. 


se 10 format text r 


Phase 10 Format Text 


xt epresentation of the FORMAT statement 5 FORMAT 
(2HOA, A6//5X,3(14,E12.5,3F12.3,*ABC')) is illustrated in Figure 51. 


ee ee ee eee 


Pointer 


T 
| 

| 

+ 

| 

| 

| 

4 

| To text for 
| next FORMAT 
| statement 
+ 
| 
+ 
| 
+ 
| 
L 


The phase 10 SF skeleton text representation of the statement function ASF (A,B,C) 
AtD*B*E/C is illustrated in Figure 52. 


p-----~-----+-+ 
| Adject 
| Code 





End ma 
}-------~-—- 
| 1 word 
eae ae a 
Figure 52. 


eet a Mel. g Gattamis vo mAs! 
ive | Chain 
I 
4 
| 
rk | 0 
age ee x eee ere een 
| 1 word 
eset Mh eae aed 
Phase 10 SF Skeleton Text 


fo a 


oes a ne re cE yor 
Mode | Type 
| 
Pies ese eee Soe {-—----—~~+~ 
0 | 0 
CE re Sapien ret seen pele eee {——————~——— 
Real | Scalar 
SP te nee ee a 4... 
0 | 0 
ac ep a cee eee ae f----—~-~—— 
Real | Scalar 
Siete eet tcl et ee a fee 
0 | 0 
beaten ie ee 4{~——~~----_~ 
| 
| 
0 | 0 
Sage Se pee peer ar ae ne ee eae 4-——+—-+—-~ 
0 | 0 
si ie area cle 7 eae eee 
1 word | 1 word 
Sa ed re nee a ay aoe a 


Appendix B: 


a ae ee cee corre ae 


Number of 
dummy 
arguments 


Intermediate Text 


se ae ee aE Te ee ee 
| 
| 
! 
| 
I 
| 
! 
{ 
! 
! 
! 
| 
' 


t 
| 
| 
| 
| 
| 
1 
! 
| 
| 
1 
1 
! 
1 
| 
| 
ad 


eee ree des ee 


—_—— 


—— 


bee come eee cnmme code ee cole mee enhen 


--{ 
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t-t- 


+ -—-— 


PHASE 15/PHASE 20 INTERMEDIATE TEXT 
MODIFICATIONS 


During phase 15 and phase 20 text proc- 
essing, the intermediate text entries are 
modified to a form more suitable for opti- 
mization and object-code generation. The 
intermediate text modifications made by 
each phase are discussed separately in the 
following paragraphs. 


PHASE 15 INTERMEDIATE TEXT MODIFICATIONS 


The intermediate text input to phase 15 
is the intermediate text created by phase 
10. The intermediate text output of phase 
15 is an expanded version of phase 10 
intermediate text. The intermediate text 
output of phase 15 is divided into four 
categories: 


Unchanged text 

Phase 15 data text 
Statement number text 
Standard text 


Unchanged Text 


The unchanged text is the phase 10 
normal text that is not processed by phase 
15. Unchanged text is passed on to subse- 
quent phases in phase 10 format with but 
one modification: the contents of the oper- 
ator and chain fields are switched. 


Phase 15 Data Text 


To facilitate the assignment of initial 
data values to their associated variables, 
phase 15 converts the phase 10 data text 
for DATA statements to phase 15 data text, 
which is in variable-constant format. The 
format of the phase 15 data text entries is 
illustrated in Figure 53. 


| Indicator field = ~~ (1 word)| 
[ Chain field ~~ (1 word)| 
hl fiela SSS wore | 
| p2 field | (1 word)| 
| Offset field ~~ (1 word)| 
| Number field =A wor) | 
Figure 53. Format of Phase 15 Data Text 
Entry 


Indicator Field: The indicator field indi- 
cates the characteristics of the initial 
data value (constant) to be assigned to the 
associated variable. This field is  con- 
tained in a full word, the high-order three 
bytes of which are not used. The indicator 
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Chain Field: 


field is divided into eight subfields, each 
of which is one bit long. The bits are 
numbered from OQ through 7. Figure 54 
indicates the function of each subfield in 
the indicator field. 


Saab le ict ae mao Be ge ee a 
| Subfield | Function j 
}--------—--- {-------------------------—- { 
| Bit 0 | not used | 
fo-—---—-——=— fanaa nnn nnn nn nnn nnn { 
| Bit 1 | not used | 
[------------ fo nanan nnn nnn nnn nnn { 
{| Bit 2 | not used | 
pram naan frm nn nnn nnn nn nnn nnn { 
| Bit 3 | not used | 
gist ae anaras ae ee a { 
] Bat 4 ‘on' | initial data value is nega-| 
| | tive constant | 
Rectan errata Na a a a tac ere | 
| Bit 5 ‘on* | initial data value is a| 
| j Hollerith constant | 
rare errs cer eure array 
| Bit 6 ‘on | initial data value is in| 
| | hexadecimai form | 
Near fmm nnn enn nin 
| Bit 7 'on" | data table entry is six] 
| | words long (variable is an| 
| | array element). | 
be oe Se ee ee J 
Figure 54. Function of Each Subfield in 


Indicator Field of Phase 15 


Data Text Entry 


The chain fiela is used to 
maintain linkage between the various phase 
15 data text entries. It contains a point- 
er to the next such entry. 


Pi Field: The Pl field contains a pointer 
to the dictionary entry for the variable to 
which the initial data value is to be 
assigned. 


P2 Field: The P2 field contains a pointer 
to the dictionary entry for the initiai 
data value (constant) which is to be 


assigned to the associated variable. 


Offset Field: The offset field contains 
the displacement of the subscripted varia- 
ble from the first element in the array 
containing that variable. If the variable 
to which the initial data value is to be 
assigned is not subscripted, this fiela 
does not exist. 


Number Field: The number field contains an 
indication of the number of successive 
items to which the initial data value is to 
be assigned. If the initial data value is 
not to be assigned to more than one iten, 
this field does not exits. 


Statement Number Text 


The statement number text is an expanded 
version of the phase 10 intermediate text 
created for statement numbers. It is 
expanded to provide additional fields in 
which statistical information about the 
text block associated with the statement 
number is stored. The format of statement 
number text entries is illustrated in Fig- 
ure 55. 


| Chain field (1 word) | 
pe—-=- 5 - - 
| Operator field (1 word) | 
fa tt 
| Pl field (1 word) | 
}-------------—--- --- ---- ------ +--+ -- 
| Block size field (1 word) | 
poe aa a es ee 
| Indicator field (1 word) | 
po--++~+--—+--=---=+-—------=----==--+--+-+-+ 
| BLKEND field (1 word) | 
eee ae eee oe ee ee 
| Use vector field (MVF) (4 words) | 
bee ee ee ee 
| Definition vector field (MVS) (4 words) | 
ee a ee 
| Busy-on-exit (4 words) | 
| Vector field (MVX) | 
epee Sep a re in, Rye ra Ic RCN SO ee 4 
Figure 55. Format of Statement Number Text 
Entry 
Chain Field: The chain field is used to 
Maintain the linkage between the various 
intermediate text entries. It contains a 


pointer to the next text entry. 


Operator Field: The operator field con- 
tains an internal operation code (numeric) 
for a statement number definition (see 
Table 25). 


Pi Field: The Pi field contains a pointer 
to the statement number/array table entry 
for the statement number. 


Block Size Field: The block size fielid 
contains the number of text entries within 
the block (started by the statement number 
for which the current text entry is made). 


Table 25. Phase 15/20 Operators 
amine ata We ee a en ty re ge 1 
| | Mnemonic { | 
|Code (in| (where | j 
| decimal) |applicable) | Meaning | 
}--------}---~-------}--~-~--~----=------- 1 
| 1 {| NOT. {NOT | 
| | i | 
| 2 |} vU jUnary minus | 
| | i | 
| 4 | .AND. | AND | 
I | | | 
| 2) i ) j|Right parenthesis | 
| | | | 
| 6 | .OR. {OR | 
| | | | 
| 8 | st {Store | 
| | { 
| 9 | os | Argument | 
| | | 
| 10 { + | Plus i 
| | [| | 
| 11 = {Minus | 
| | | | 
| 12 | #* | Multiply | 
| | | | 
i 13 ij 7 |Divide | 
| | | | 
| 14 {| LA jLoad address | 
| | | | 
| 15 | EXT JExternal function or| 
| | jsubroutine CALL 
| | | | 
| 16 | BG {Branch greater than | 
| | | | 
| 17 } BL {Branch less than | 
I | | | 
| 18 | BNE {Branch not equal | 
| | a | 
| 19 | BGE {Branch greater than | 
| | jor equal | 
| | | a. 
| 20 | BLE |Branch less than or | 
I | |equal | 
| | i 
| 21 | BE {Branch equal | 
| | | | 
| 22 | SUB |Subscript | 
I | | | 
| 23 | LIstT jI7O list | 
| | | | 
| 24 t Bc {Branch computed | 
| I | 
| 25 { jLeft parenthesis | 
| | | 
| 26 | jEnd mark | 
| | | | 
] 27 } B | Branch | 
| | | | 
| 28 {| BA {Branch assigned | 
| | | 
| 29 | BBT {Branch bit true | 
See ee nee Ney 5 ene a A nO gre ae ieee ne rae een ee J 
(Continued) 
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Table 25. 


Phase 15/2 


0 Operators (Cont.) 


eae Ws ia gy eS ee es fee pe ee ta 1 


Mnemonic 


{Code (in| (where 
| decimal) |applicable) 


! 
! 
1 
{ 
| 
| 
| 
| 


[Pe eee cates ree ee meee ee eee SS ee ES ee ERE Ge nee SD Se ES SS RN RT SE ES ES SE RD SEN AE NS OS A SR NN Se GN SS SR ST A AA A SS SR Skee SN mee Se SNES een SES eee 
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W WwW 
ee Oo 


eo 
ive) 


33 


34 


35 


36 


37 
39 
41 
42 
43 


44 


45 


46 


47 


50 


51 


52 


53 


54 


55 


56 


57 


+ 


Frm mre eee ce eee me ms em cre ee cre ee ee ce ree re cree eee ee ee ee re ee Ree Se Ee Re See EE SS NS SS ED OS A ee SS SD SS SS SES ES Se A See SS Se See A eee see 


BBF 
LBIT 


BGZ 


BLZ 


BNEZ 


BGEZ 


BLEZ 


BEZ 
NMLS 
BF 
BT 
LDB 


LIBF 


RS 
LS 
BXHLE 
LE 


GE 


EQ 
LT 
GT 
NE 


MAX2 


Meaning | 


| 
foaa anon nanan == { 
| 


{Branch bit false 
| 


jJLogical value of bit 


|Branch greater than 
| zero 


| Branch less than 
| zero 


| Branch not equal 
| zero 


|Branch greater than 
Jor equal zero 


{Branch less than or 
Jequal zero 


|Branch equal to zero 
| NAMELIST 


|Branch false 


|Branch true 
| 
{Load byte 


{Library function 
Jcail 


| 

{Right shift 

| 

jLeft shift 
|Branch on index 


jLess than or 
(eee than 
j equal 

Jone 

[Less than 


{Greater than 


| 
|Not equal 


equal 


or 


| 
|MAX2 in-line routine 


| 

|MIN2 in-line routine 
|DIM in-line routine 

{IDIM in-line routine 


BS ee ee A ee 
(Continued) 


| 
| 
| 
| 
i 
| 
| 
| 
I 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
{ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
4 


T 


able 25. 


Phase 15/72 


0 Operators (Cont.) 


[ene We a) es Ste, Mite? Shot a ON Gh Ne eS a 1 


Mnemonic 


{Code (in| (where 


| decimal) |applicable) | 


+ 


(Ee re cee es ee es ee ee EN OE NS A SS RY OS EL A RE OS SN A A SS LS A A A SV AS cD cet 


ON 
Oo 


ON 
nay 


62 


63 


64 


65 


66 


67 


68 


69 


71 


72 


13 


74 


75 


76 


77 


78 


79 


80 


81 


82 


83 


+ 


ee ee ee en ee we ee en een en ene ee eee ee eee ee eee een ss ee ee en nnn ne ean anna ns ss 


MOD 


AMOD 


DSIGN 


SIGN 


ISIGN 


DABS 


ABS 


TABS 


IDINT 


INT 


HFIX 


IF IX 


DFLOAT 


FLOAT 


DBLE 


BITON 


BITOFF 


BITFLP 


ANDF 
ORF 


COMPL 


MOD24 


| 
| 
{ 
| 
I 
| 
I 
| 
| 
| 
| 
= 
{ 
| 
1 
| 
I 
! 
! 
I 
! 
I 
| 
! 
| 
| 
| 
| 
' 
| 
\ 
{ 


Meaning i 


Sid ee ee ee | 
| 


j{DMOD in-line routine] 


—+ 


{MOD in-line routine 


JAMOD in-line routine 


|DSIGN in-line rou- 
jtine 


{SIGN in-line routine 


| 
| 
| 
| 
| 
| 
| 
| 
| 
JISIGN in-line rou- | 
jtine | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 


j|DABS in-line routine 


JABS in-line routine 


|IABS in-line routine 


JIDINT in-line rou- 
{tine 


JINT in-line routine | 


| 
JHFIX in-line routine| 
| | 


| IFIX in-line routine] 


| 
{DFLOAT in-line rou- 
{tine 


JFLOAT in-line rou- 
jtine 


|DBLE in-line routine 


{BITON in-line rou- 
jtine 


|BITOFF in-line rou- 
jtine 


|BITFLP in-line rou- 
jtine 


JANDF in-line routine 
jORF in-line routine 


{|COMPL in-line rou- 
jtine 


|MOD24 in-line rou- 
{tine 


{LCOMPL in-line rou- 
jtine 


lee eee cee SR es SY meses SE meme MS Ss eee ge ee ee eee Re ee ee UE ee SE a 


(Continued) 


Table 25. Phase 15/20 Operators (Cont.) 
fo esa te ae ne ee a Gee 1 
| Mnemonic | | 
|Code (in| (where | | 
| decimal) |applicable) | Meaning | 
}-------- $----------- }-------------------- { 
| | | i | 
| 85 | SHFTR {SHFTR in-line rou- | 
| | {tine | 
I | | | 
| 86 | SHFTL | SHFTL | 
| | | { 
| 100 | LR [Load register (phase] 
| | {20 only) | 
| | | 
{ 101 ] Rc jRestore main storage| 
| | | (phase 20 only) | 
| | | | 
{ 102 {| RR {Restore register | 
| | { (phase 20 only) | 
| | | | 
| 103 | {Register usage | 
{ | | (phase 20 only) | 
| i | | 
{| 193 | |BLOCK DATA | 
| | | 
} 200 | | COMMON | 
| | 
{| 201 | | EQUIVALENCE | 
| | | | 
| 202 | | EXTERNAL | 
| | | | 
} 205 | | DATA | 
| | | | 
| 208 | | FUNCTION | 
| | | 
| 209 | | FORMAT | 
i | | | 
{| 210 | JEND I/70 | 
| | | | 
} 211 | | CONTINUE | 
| | | | 
f 2h3 | jObject time FORMAT | 
| | | | 
|} 214 | | BACKSPACE | 
| | | | 
1. 225 | | REWIND | 
I | | | 
| 216 | JEND FILE | 
| | | | 
{| 217 | |WRITE unformatted | 
i | | 
| 218 | |READ unformatted | 
l | | | 
j 219 | {WRITE formatted | 
| | | | 
{| 220 | {READ formatted | 
| I | | 
| 221 | {Begin I/0 | 
| | | | 
{} 222 | LDF {Statement number | 
| | | definition | 
i I | 
} 223 | GLDF {Generated statement | 
| | {number definition | 
| eae ee ee 5 ele oe ae eee ao ee ae i Ss ee lata es J 
(Continued) 


Table 25. Phase 15/20 Operators (Cont.) 
[sao e Nae ee SY ee eae eg ee s 
| Mnemonic | | 
{Code (in| (where | | 
|decimal) |applicable) | Meaning | 
}-------- }----------- }--------~----------- { 
| I | | 
} 224 | | IMPLICIT | 
| | { 
| 225 ] |WRITE using NAMELIST| 
| | | | 
{| 226 | [READ using NAMELIST | 
| | | | 
| 227 ] |Statement function | 
| | | | 
| 230 | {I/O end-of-file | 
| | |parameter | 
| | | | 
| 231 | }I/O error parameter | 
| | | | 
| 232 | | BLANK | 
| | | 
} 233 {| RET | RETURN | 
| | | | 
| 234 | STOP | STOP | 
| | | | 
} 235 | | PAUSE | 
| | | | 
{ 249 | END | END | 
| | | 
} 251 | {I/O unit number | 
bon oeee heat ast Aer eee J 
Indicator Field: The indicator field is 


contained in a full word, the high-order 
three bytes of which are not used. This 
field indicates some of the characteristics 
of the text entries in the associated 
block. The indicator field contains eight 
subfields, each of which is one bit long. 
The subfields are numbered 25 through 32. 


Figure 56 indicates the function of each 
suofield in the indicator field. 
aaa TESS a taiet iat Ee ee ee 1 
| Subfield {| Function | 
}------------- 4~-------------------------- { 
| Bits 25-28 | not used | 
pomnnnn a= fon nn neers 
| Bit 29 ‘on' | associated block contains | 
| | an I/O operation | 
Serie ang fe 
| Bit 30 ‘on" | associated block contains} 
| | a reference to a library| 
| | function | 
}------------- $--------------------------- : 
| Bit 31 | not used | 
}----—------- 4------~---~--------------=-- 
| Bit 32 ‘on' | associated block contains| 
| | an abnormal function ref-| 
| | erence | 
Leen es iu le Deca Se nes eke, J 
Figure 56. Function of Each Subfield in 
Indicator Field of Statement 


Number Text Entry 
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BLKEND Field: The BLKEND field contains a 
pointer to the last intermediate text entry 
within the block. 

Use. Vector Field (MVF): The use vector 
field is used to indicate which variables 
and constants are used in the associated 
block. Variables and constants, as they 
are encountered in the module by phase 15, 
are assigned a unique coordinate (1 bit) in 
this vector field. In general, if the ith 
bit is on (1), the variable or constant 


assigned to the ith coordinate is used in 
the associated block. 
Definition Vector Field (MVS): The defini- 


tion vector field is used to indicate which 
variables are defined ina block. Varia- 
bles and constants, as they are encountered 


by Phase 15, are assigned a unique coordi- 
nate (1 bit) in this vector field. In 
general, if the ith bit is on (1), the 


variable assigned to the ith coordinate is 
defined in the associated block. 


Busy-On-Exit Vector Field (MVX): The busy- 
on-exit vector field in phase 15 indicates 


which variables are not first used and then 
defined within the text block (not 
busy-on-entry). This field is converted by 
phase 20 to busy-on-exit data, which 
indicates which operands are busy-on-exit 
from the plock. Variables and constants, 
aS they are encountered by phase 15, are 
assigned a unigue coordinate (1 bit) in 
this vector field. In general, during 
phase 15, if the ith bit is on (1), the 
variable assigned to the ith coordinate is 
not busy-on-entry to the block. During 
phase 20, if the ith bit is on, the 
variable or constant assigned to the ith 
coordinate is busy-on-exit from the block. 


Standard Text 


The standard text is an expanded and 
modified form of phase 10 intermediate text 
that is more suitable for optimization. 
The format of standard text entries is 
illustrated in Figure 57. 


Chain Field: The chain field is used to 
maintain the linkage between the various 
intermediate text entries. It contains a 


pointer to the next text entry. 


Operator Field: The operator field con- 
tains an internal operation code (numeric) 
that indicates either the nature of the 
statement or the operation to the performed 
(see Table 25). 


Pl Field: The Pl field contains either a 
pointer to the dictionary entry or state- 
ment number/array table entry for operand 1 
of the text entry, or zero (0) if operand 1 
does not exist. 


154 


Wak ae he ogy ee rare get rete aT ga Tyee 1 
| Chain field (1 word) | 
[----------------------------------------- 1 
| Operator field (1 word) | 
bose eee Se a a a eee 
| Pil field (1 word) | 
Pees oet ee ee eee ce eee eee eS 
| P2 field (1 word) | 
| --------------------------------~=------- { 
| P3 field (1 word) | 
}------ 1 cEaEnPaaPSUnian SRRREREIE Semaataes peaneies reece { 


T T T 
| Not |S | Mode 


|field]| field 


+ 
Not {Used by |D 
used |phase 20]|fielid|used 
(bits| (bits j( bit | (bits | (bit | (bits 


| | 
| : 
|} 0-1) |2-13) }14) $15-25)|26) |27-31)]| 
-~--—--- a 5 eee fa eae Be fee ees | 
| Not | | 
| used | Used by phase 20 | 
| (bits | (bits 8-31) | 
| 0-7) | | 
}------4-----------~---------------------- { 
| Displacement field (1 word) | 
Poe ee eas a er re J 
Figure 57. Format of a Standard Text Entry 
P2 Field: The P2 field contains either a 


pointer to the dictionary entry for operand 
2 of the text entry, a pointer to an IFUNTB 
entry, or zero (0) if operand 2 does not 
exist. 


P3 Field: The P3 field contains either a 
pointer to the dictionary entry for operand 
3 of the text entry, a pointer to a 
parameter list in the adcon tabie, an 
actual constant (for shifting operations), 
or zero (0) if operand 3 does not exist. 


D Field: The D field only has meaning for 
division operations. A setting of 0 signi- 


fies division, and indicates that tne quo- 
tient is to replace operand 1. A setting 
of 1 signifies a MOD operation, and indi- 


cates that the remainder is 


operand 1. 


to replace 


S Field: The S field indicates whether or 
not a text entry is involved in a subscript 
computation. (If the S bit is on (1), the 
text entry is part cf a subscript computa- 
tion.) 


Mode _ Field: The mode field indicates the 
general mode of the expression and the mode 
of the operands. The bits are set by phase 
15. The meanings of the bits in the mode 
field are given in Table 26. 


Displacement Field: The displacement field 
appears only for subscript and load address 
text entries; it contains a constant dis- 
placement (if any) computed from constants 
in the subscript expression. 


Table 26. Meanings of Bits in Mode Fieid of Standard Text Entry 


SSeS SS y Kener rane Oe et eg PRT eI gO eS at gy Sy ge ae ERR 7 
| Mode |. Bats | Meaning | 
}----------- ¢--------- fanaa nnn nanan nnn nnn nn nn nnn nnn 1 
| aqeneral | 27-28 | OO - logical | 
| | ] O01 - integer | 
| | | 10 - real | 
}----------- }+--------- }~----------------------- <= --- === -- === =~ = === 5 5-5 { 
} operand 1| 29 | 0 ~ short mode(logical*1, integer*2, real*4) | 
| | | 1 - long mode (logical*4, integer, real*8) | 
|----------- }--------- f---------------------------------=---=--------------------- === { 
{ operand 2| 30 | 0 - short mode (logicai*i, integer*2, real*4) | 
| | | 1 - long mode (logical+4, integer, real*8) | 
}----------- $--------- }-------~~--- ~~~ === <= -- 3-5 - === { 
| oOperand 3| 31 | 0 - short mode (logical*1, integer*¥2, real*4) | 
| | | 1 - long mode (logical*4, integer, real*8) | 
bse eet per eae e ae eet eee SOR SY CE a re et et Re emo Pe aan ee aN Py RT Pye Pm Nee ONE a or ne ECE Co a 


PHASE 20 INTERMEDIATE TEXT MODIFICATION 


The intermediete text input to phase 20 is the output text from phase 15. The 
intermediate text output of phase 20 is of the same form as the standard text output of 
phase 15. The format of the phase 20 output text is illustrated in Figure 58. 


Ri, R2, and R3 Fields: The R1, R2, and R3 fields (each is 4 bits long) are filled in by 
phase 20 during register assignment, and are referred to by phase 25 during the code 
generation process. The assigned registers are the operational registers for operand 1, 
operand 2, and operand 3, respectively. 


Bi, B2, and B3 Fields: The Bi, B2, and B3 fields (each is 4 bits long) are filled in by 
phase 20 during register assignment, and are referred to by phase 25 during the code 
generation process. The assigned registers are the base registers for operand 1, operand 
2, and operand 3, respectively. 


Status Field: The status field is composed of 12 bits that are set by phase 20 to 
indicate the status of the operands and the status of the base addresses of the operands 
in a text entry. The information in the status field is used by phase 25 to determine 
the machine instructions that are to be generated for tne text entry. The status field 
bits and their meanings are illustrated in Table 27. 


{| Chain field + (1 word) | 
po -- === === 2 nn nnn nnn nn nnn nn nnn { 
| Operator field 1+ (1 word) | 
pea == $= nnn nnn nnn nnn nnn { 
| Pi field 1+ (1 word) | 
}---------------------------------------------------- === === +--+ == === === == === === - { 
| P2 field + (1 word) | 
Sata PP { 
| P3 field + (1 word) | 
Sara Resi palatine’ dan ie PTR CSRIRRICR, (at eau CA BSR CES ie a ine SeaTac ac mire 
{Not used | Status field | D fielid* | Not used { S fieidt | Mode field | 
{(bits 0-1)| (bits 2-13) |} (bit 14) | (bits 15-25) | (bit 26) | (bits 27-31) | 
Poeed Seed narste. 4{--------~---7 Sieg Ee ae ERMA: GRIM aE aR em eae ere Da 
jNot used | R1 field | Bi field | R2 fieid | B2 field | R3 field | B3 field | 
| (bits 0- lee 8- rae oes 1 2= sane Covecodes 16- ee ae 20- Fini es ctahas 24- ibe Neake 28-31) | 
}---~------4-----------1------------1--~-------—--41-------~----1--~---------4------------ 
| Biniee ase field a word) | 


t 

j+The chain field, mode field, operator field, P1 field, P2 field, P3 field, D field, S | 
| field, and displacement field are as defined in a phase 15 standard text entry. | 
| (Phase 20 does not alter these fields.) 


Figure 58. Format of Phase 20 Text Entry 
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Table 27. Status Field Bits and Their Meanings 


(SSS SS se ees rai aaa ha Ac eM a Ra a a Oa la 
| Operand/ | | 

| Base Address | Bit | Meaning 

}-------------------- +----------- }----------------------------------~------------------- 
| | 2 | 0 - base address in storage 

| Operand 2 | | 1 - base address in register 

| base address | | 

| status | 3 | 0 - do not retain pase address in register 

| | | 1 - retain base address in register 
}--------~----------- }~---------- }----=---------------- -------------- === === == 
| | 4 | 0 - base address in storage 

| Operand 3 | | 1 - base address in register 

| base address | | 

| status | 5 | 0 - do not retain base address in register 

| | | 1 - retain base address in register 
}-------------------- }----------- }--~------------------~-------------------------------- 
| | 6 | 0 - operand in storage 

| Operand 2 | | 1 - operand in register 

| status | | 

| | 7 | 0 - do not retain operand in register 

| | | 1 - retain operand in register 

p——- === - eee }----------- {~------------------~---~~-----=------------------------ 
| | 8 | 0 - operand in storage 

| Operand 3 | | 1 - operand in register 

| status | | 

| | 9 | 0 - do not retain operand in register 

| | - | 1 - retain operand in register 
[--~----------------- rar foam nnn nn nn nnn nnn nnn ncn 
| | 10 | 0 - base address in storage 

| Operand i | | 1 - base address in register 

| base address | | 

| status | ia | 0 - do not retain base address in register 

| | | 1 - retain base address in register 
}~------------------- $----------- }----------------------------------+------------------- 
| | 12 | 0 - generate store into operand 1 

| Operand 1 | | 1 - do not generate store into operand 1 

j status | | 

| | 13 | - not used 

Doe ee eee re acetate eet ch et i a oe a ae 


STANDARD TEXT FORMATS RESULTING FROM PHASES 15 AND 20 PROCESSING 


The following formats illustrate the standard text entries developed by phase 15 and 
phase 20 for the various types of operators. When the fields of the text entries 
differ from the standard definitions of the fields, the contents of the fielcs are 
explained. In addition, notes that explain the types of instructions generated by 
phase 25 are also included to the right of the text entry format, when appropriate. 
For an explanation of the individual operators see Table 25. 
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J 


| 


Branch Operator (B) 


Sa ee ere eg ee ee 1 
{Chain (1 word) | 

i aha ne ee es a ee aa 4 
|Branch operator (1 word) | 
|P1 (1 word) | 
}—--------~-_-_-_-_-.-_-_~/» ___-_/ -_-----_-------- 
| (1 word) | 
}----+-~--~---~--~------~+~---------~-~--~--~-- 
| (1 word) | 
icc ease aunt ace aoe (oe) Ce meal a cee 4 
| | Status | | 1 1 | 
fsssrer ee 4 p—---y---4 -t---7~----4 4-4-7 ----4 
| | | | | { | I 
leewo sees 1 ee! Ceneceoen! eee nen letee eee shes ee eeu 
Logical Branch Operators (BT, BF) 

a a ga a aerate se Sa 4 
[Chain (1 word) | 

NEE Pe ape as eR ae eT RR rE NaN re OND eS ET 4 
{Logical branch operator (1 word) | 
{P1 (1 word) | 
jP2 (1 word) | 
| ----------------------------------------- { 
| (1 word) | 
ese aa eae Cores a Sian ons lads Rua alaaeon Gai See werN ae 
| | Status | | | | Mode | 
Sea eae 4 p-—--—y———4 pt--- 7 ----, 4-4-7 ----{ 
! I | | R2 | B2 | | | 
bok eee. Ste eae a eee ee ed oo 


Binary Operators (+, -, *, 7, OR, and AND) 


[oo ee ee 1 
| Chain (1 word) | 
f--+--—-——--+—----+~—-+--- +--+ = - +--+ 
{Binary operator (1 word) | 
{P21 (1 word) | 
| P2 (1 word) | 
| P3 (1 word) | 
eas aaa, Ca an ce 9 Di name es , an Senin: 
| | Status |DI | { Mode | 
}---------- yi eee eR npr 4 tp cy eeepc eeeteta 
| | Ri | BL | R2 | B2 | R3 | B3 | 
Pee Seas. Pee a i Beeneeeeawes Rea | 


Pi: The Pi field contains a pointer to tne 
Statement number/array table entry for the 
statement number branched to. 


Note: Phase 25 decides if an RR or an RX 
branch instruction should be generated. 


Pi: The P1 field contains a pointer to the 
statement number/array table entry for the 
statement number being branched to. 


P2: The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 


Note: The test of the logical variable 
will be done with a BXH or BXLE for BT and 
BF, respectively. 
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Test and Set Operators (GT, LT, GE, LE, EQ, 
Ce ee i ee 1 
{Chain (1 word) | 
|Test and set operator (1 word) | 
|P1 (1 word) | 
| P2 (1 word) | 
{P3 (1 word) | 
[oaeeaeen Tove Met eet ee 2 hae arta aria { 
| | Status | | j} | Mode | 
}--------—-- ip ea bplseeee oe qiat = 
| j RL | BL | R2 | B2 | R3 | BB |} 
ieee eos  ERMa ects ose REN Bra bre Neen Hertecn ae Renee: ene | 


In-line Functions (MAX2, MIN2, DIM, 


LCOMPL, IDIM, BITON, BITOFF, AND, OR, COMPL, 
Pat oe ee ge ge apa ee eee 1 
}Chain (1 word) | 
bee Sa ee ee ee ee ee ee 
{Function Operator (1 word) | 
{Pi (1 word) | 
| P2 (1 word) | 
|P3 (1 word) | 
fare SSrS Say a Faia al : Savane 
| | Status |DI | | Mode | 
}---------- 1 p----y--- 4 -1---7---- yt-4-7----] 
| { Rl | Bl | R2 | B2 | R3B | B3 | 
teen Sess seed Geert: eee nen: UR ewe at B keane teey leaner | 


Re ee ee a ee 1 
|Chain (1 word) | 
}-----------------------~----------------- { 
|LDB operator (1 word) | 
| P1 (1 word) | 
[----------------~------------------------] 
|P2 (1 word) | 
(Se eee ee ee ee ee 
| (1 word) | 
area a ca Cea taeerea (ais) a Rel Se Ss 
| | Status | | | | Mode | 
[oSeankeae= sa Taasgeh Sai San Coach EALacace : ea ae aE 
| | R1 | | R2 | | R3 | B3 | 
Se ee ARES ets Semen Conte bepseden cabanas 
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IDIM, DMOD, 





and NE) 


MOD, AMOD, DSIGN, SIGN, ISIGN, LAND, LOR, 
MOD24, SHFTR, and SHFTL) 
Note: The LDB operator is used to load a 


register with a byte logical variable. 


Branch on Index Low or Equal, or Branch on Index High 


| Chain (1 word) | 

| Add operator (1 word) | 

| Pl (1 word) | 

| P2 (1 word) | Text 
---------~------------—------------ 4 Entry 1 
{ P3 (1 word) | 

asia a Ne eS ial Pen ee Coe Te { 

{| | Status | | 1] | 

(et eae er eae 

| | | | R2 | | R3 | B3 | 
Da ee ee a he 

pee oe ee ee 

{| Chain (1 word) | 

| Branch operator (1 word) | 

{| Pi (1 word) | 
}--—---~----—~------~--------~---- { 

} P2 (1 word)| Text 
}--------------------------------- qf Entry 2 
| P3 (1 word) | 

ee cea arr aaa So Tiss oeee ee te { 

{ | Status | ! | | | 

}~~41 -----,---1 ,L-—-,--=-- fey See 

| | | | R2 | | R3 | B3 | 

becs teeta eho i eee See | 


Computed GO TO Operator 


Ba ge Ps he Cie OG ep ig ee eae 1 
{Chain (1 word) | 
{Computed GO TO operator (1 word) | 
| Pi (1 word) | 
| P2 (1 word) | 
paeeee ee ee eet ee 
| P3 (1 word) | 
fer a ea ee Tse s= { 
| | Status | | 1 | | 
}--~-------~ pee ce pest ple 5 as Seay en ee 
| | | l | B2 { R3 | B3 | 
ean ere ave Bac Dae a ed 


Note: A BXHLE instruction will be generat- 
ed by phase 25 when an add operator is 
followed by a branch operator. 


Pl and P2 of text entry 1 equals P2 of 
text entry 2. 


Pi: The Pi field of text entry 2 contains 
a pointer to the statement number/array 
table entry for the statement number being 
branched to. 


Pi: Pi contains the number of items in the 
branch table that are associated with the 
computed GO TO operator. 


P2: P2 contains a pointer to the informa- 
tion table entry for the branch tabie. 


P3: P3 contains a pointer to the indexing 
value for the computed GO TO statement. 
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Branch Operators (BL, BLE, BE, BNE, BGE, BG, BLZ, BLEZ, BEZ, BNEZ, BGEZ, and BGZ) 


a a ee a a a i es 8 ee ee ee ee ee 


|Chain (1 word) | 
|Branch operator (1 word) | 
{P12 (1 word) | 
| P2 (1 word) | 
jP3 (1 word) | 
aeRO Gee a caer (ead Reece eras 1 ie ca 
| | Status | | | | Mode | 
PSSSsearers a Casa: aimed daseetece Sasetay aie Resale | 
| | | | R2 | B2 | R3 | B3 | 
Disoge ees es Diet hoeebeee boo y ceeircareey Wem oesnee 


Binary Shift Operators (RS, LS) 


Bp Sc ee a he eras es ge 1 
|}Chain (1 word) | 
}----------------------------------------- { 
{Binary shift operator (1 word) | 
{P21 (1 word) | 
| P2 (1 word) | 
{Shift quantity (1 wora) | 
terrace {o=-=s-2-—> a ae aaa 1 is ee { 
| | Status | | | | Mode | 
eSSeesSsee 4 p----7---4 -4---7---- L-4-7----{ 
| | | {| R2 | B2 | R3 | B3 | 
bee saa Me eee LO eed 
Load Address Operator (LA) 

Ca ee ee ee 1 
{Chain (1 word) | 
eo a ac ce aah Ea aa tt eat J 
|Load address operator (1 word) | 
{PL (1 word) | 
| P2 (1 word) | 
| P3 (1 word) | 
ceria nec ; ae a ests op 5 See aaeaeanes { 
| | Status | | {S| Mode | 
Peer esoesas dpa pee yee 
| | R1 | {| R2 | | R3 | B3 | 
bee ee Soe caer Carey (eee Menreces [manecaren! Gouna 
{Displacement (1 word) | 
Wigan ee ae et J 


Pi: The Pl fieid contains a pointer to tne 
statement number/array tabie entry for the 
statement number being branched to. 


Note: Operands 2 and 3 must be compared 
before the branch. Fcr the BLZ, BLEZ, BEZ, 
BNEZ, BGEZ, and BGZ operators, operand 3 is 
zero and a test on zero is generated. 


Note: The purpose of the loaa address 
operator is to store an address of an 


element of an array in a paraneter List. 
The Pl field defines the parameter list. 


Subscript Text Entry - Case 1 


Bath she saat ee ee hee a a ee ei 4 
|Chain (1 word) | 
}----------------------------------------- { 
|Subscript operator (1 word) | 
be eee eee ae ee ee Sa ee ee ee 
|P1 (1 word) | 
{P2 (1 word) | 
|P3 (1 word) | 
fase Ssesae : Rei, » a eae as | Oe: caine { 
| | Status | | {S| Mode | 
[SSS —ess-= 4 p-~——-y-—- 4 pt —- 7 ---- 7 4-1-7 ----|{ 
| } R1 | BL | R2 |] B2 { R3 f BB | 
EN ae MARRS fern: Geeeenaes eens Maree wee Ween Geer eee 
|Displacement (1 word) | 
Bites ste eae Ahh ee a J 
Subscript Text Entry - Case 2 
Caer re ep ee pe ny pe ee A 
[Chain (1 wora) | 
Sate eesei Seo ate Sh ee ee | 
|Subscript operator (1 word) | 
ape eee ee ee 
| (1 word) | 
| P2 (1 word) | 
{P3 (1 word) | 
iano nemo | Aceon : ec aa 1 SE Sana lem { 
| | Status | | {S| Mode | 
ema aaa ta A p————_--— 4 pt -~ 7 ---- 7, 1-4-7 ----{ 
| i | | {| B2 | R3 | B3 | 
Raped are ee DRED! UC SRY (reemneen! Sree Beene, 
|Displacement (1 word) | 
a ag a see J 


P2: The P2 field contains a pointer to the 
dictionary entry for the variable being 
indexed. 


P3: The P3 field contains a pointer tc the 
dictionary entry for the indexing value. 


Note: For Case 2 subscript text entries, 
the subscript text entry is combinea with 
the next text entry to form a single RX 
instruction. (Case 2 will be formed by 
phase 15 only when the second text entry 
has the store operator. Phase 20 will 
change Case 1 text entries to Case 2 text 
entries when appropriate.) 


Pl is zero and either P2 or P3 of the 
next text entry will be zero. 


In-line routines (DABS, ABS, IABS, IDINT, INT, HFIX, DFLOAT, FLOAT, DBLE) 


aaa aa mala aa areca eae! 1 
Chain (1 word) | 
I pe ate RA aR OM AE nS OT ae EG OO EER eR See, TE ER { 
Operator (1 word) 
p 
{P1 (1 word) | 
| P2 (1 word) | 
bona a ee ee se 
| (1 word) | 
rem ; Sams Saas aoe T7777 Tt 1 
| { Status | | | | Mode | 
t---------- 4 p----y--- 4 -t---+---- y+-1+-7----{ 
| | R1 | Bl | R2 | B2 | | | 
bate ee er iT eet Lem 
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EXT, and LIBF Operators 


Ge se a ee Oe ree eg ee eee 1 
} Chain (1 word) | 
a pa i a a Sa a a es ga 4 
| Operator (1 word) | 
bee ee rie eee 
{PL (1 word) | 
A Ret a ie ee ne A eS ee ear 4 
{P2 (1 word) | 
Pease ae ee a te eee ee eee 
{P3 (1 word) | 
Presta s Sere ea oT qa 1 ie Cae | 
| {| Status | | 1 | | 
fSese= esos ml ac reat Soa A plese esate tege a4 
| {| R1 | Bi | | | | | 
bos Seca oe eee Ol ca aN I a a 
Arguments for Functions and Calls 

a ae ee re ee ee ee 1 
|Chain (1 word) | 
}--------~-------------------------------- { 
|Argument operator (1 word) | 
| P1 (1 word) | 
}-—-------~---~---------+~--------—~+-------- 
| P2 (1 word) | 
}P3 (for complex) (1 word) | 
[Sseessee= === == [ot -1-T-- 
| | 1 | 1 | | 
fosSsesaseS 4 p-——— zh dy -- 7 4-4-4 
| | | I | | | | 
CE en er nae ao eee es Leena Comer! Seman ey | 


Pi: Pi is zero for the EXT operator of a 


subroutine call. 


P2: The P2 field contains either a pointer 
to the dictionary entry for an external 
function or a subroutine name, or a pointer 


to the IFUNTB entry for a library function. 


P3: The P3 field contains either zero or a 
symbolic register number and a displacement 
that points to the object-time parameter 
list of the external function, library 
function, or subroutine. 


Note: No registers are needed for this 


type of text entry. 


For calls and ABNORMAL functions, Pl = 
P2. For NORMAL functions and library func- 
tions, Pil = 0. 


See the next text entry for the case of 
compiex statements. 


Special Argument Text Entry for Complex Statements 


a eg ee a ea 1 
[Chain (1 word) | 
|~---------------------------------------- : 
|Argument operator (1 word) | 
ey Sade ae ra ESO ee EE RO MEIE Ne se Pe nt oe Pen RE oe EE 4 
{Pi (1 word) | 
}--—----------~--_~--.-----~- -.---------.- 
| (1 word) | 
}---~--~-----~+--------—-----~--+-----+++-- 
| (1 word) | 
SS a ae 5 Ft Getencaiee ae 1 
| | Status | | | | | 
aol aia eo a) Cais Seseneron: Geiance cacetaies ‘wetarecre fammiara | 
| {| RL | Bi | | i | 
epee ana ee Pee Waco ke i eee Serene CRMEMIES 
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Note: For complex statements, the first 
text entry of the argument list contains 
the register information for the imaginary 
part of the complex resuit. 


Assigned GO TO Operator (BA) 


Pe ee re ee es ee ee 1 
| Chain (1 word) | 
ba eS Se Se a eee eee eee 
|Assigned GO TO operator (1 word) | 
be ee ee ee eee 
| (1 word) | 
| P2 (1 word) | 
|------------------~-------~-------------- { 
| (1 word) | 
aca ara | a eco aan Sa Ca aa 5 Ca a eames 4 
| | Status | i i | | 
SSSesete > dpe saya yt tage og te tee 
| | | | R2 | B2 | | | 
Dots oe | ee CORE Se! SORE! SAN OIGE energy) mre se! 


READ/WRITE Operators for I/O lists 


READ 
a ee 1 
{Chain (1 word) | 
a aM Re Me ae er PINE eV A Se Re ree Pen era ree poe 4 
{READ operator (1 word) | 
ba ee ee ee ee ee 
| P1 (1 word) | 
}~-------—~—---~-----+~+----+----+-+------+- 
| (1 word) | 
Fae OR aL pao fy es a et Oe Mt ed aM gg, See ye eee ee { 
|P3 (1 word) | 
Paar a Sarena oe Canty aera aces a a aaa tcc { 
| | Status 1! 1 | | 
esos he aeciecasieatad A pam 1-7-7 4-1-7 { 
| | Ri { Bi | | | | | 
beeen ea d CER CORRE CRE OY ETE LAP GR ON NonRA weet: 
WRITE 

a a Sk a a a EOE | 
{Chain (1 word) | 
|WRITE operator (1 word) | 
}-----~-----+~~-----~~----+~—~---++---------- 
| (1 word) | 
[P2 (1 word) | 
| P3 (1 word) | 
ie aoe ea (abe neeeron ia, cane as sae ian 1 
| | Status ie { | I 
poses ss peg pod 
| {| R1 | Bl | | | | | 
a eer a 1 apap wres ERR AMNI SenMapey Err Money! Weceeyey es loess. a 


P2: The P2 field contains a pointer to the 
variable being used in the assigned GO TO 
statement. 


Pi: The P1 field contains a pointer to the 
I/O list for the READ statement. 


Note: If the P3 field contains a zero, an 
entire array is being read. This causes a 
different instruction sequence to be gener- 
ated. 


P2: The P2 field contains a pointer to the 
I/O list for the WRITE statement. 


Note: If the P3 field contains a zero, an 
entire array is being written. This causes 
a different instruction sequence to be 
generated. 
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Logical Branch Operators (BBT, BBF) 


am as a aa aoe a 1 
{Chain (1 word) | 
a arena ea ee re eee Wa Neer Nees Ree een ee eee 4 
jLogical Branch Operator (1 word) | 
|P1 (1 word) | 
| P2 (1 word) | 
|P3 (1 word) | 
a ca a a 5 ae a oe aaa 
| | Status | | {| | Mode | 
[---------- 1 p—---7--- 4 ,-1---7---- yt-t-7----4 
| } Ri | | | B2 | | | 
Poe ce en (ene eS Leo aN ReReRSa, SSE, Severn J 
LBIT Operator 

Scie ae eS es Se eee ee eae 
|Chain (1 word) | 
erie Se err ia i a ene 1 
| LBIT Operator (1 word) | 
| P1 (1 word) | 
|P2 (1 word) | 
| P3 (1 word) | 
[eoeessssS pe Sse A a aaa ote sh Seanad { 
| | Status | | | | Mode | 
presse Sssr5 sal Gecieceies Vestal tecteacca, (norearaenay Vaceiagea Scammed | 
| l | | | B2 | | i 
be eh ee et oa 
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Pi: The Pi field contains a pointer to the 
statement number/array table entry for the 
statement number being branched to. 


P2: The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 


P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 


P2: The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 


P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 


The major arrays of the compiler are the 
bit strip and skeleton arrays, which are 
used by phase 25 during code generation. 
The following figures illustrate the bit 
strip and skeleton arrays associated with 
the operators of text entries that undergo 
code generation. The skeleton array for 
each operator is illustrated by a series of 
assembly language instructions, consisting 
of a basic operation code, which is modi- 


fied to suit the mode of the operands, and 
operands, which are in coded form. The 
operand codes and their meanings are as 


follows: 
Bn--base register for operand n 


BD-~base register used for loading an 
operand's base address 


Rn--operational register for operand n 
X--index register when necessary 


To the right of the skeleton array for 
an operator is the bit strip array for the 
operator. Each bit strip in the bit strip 
array consists of a vertical string of 0's, 
1's, and X's. A particular strip is 
selected according to the status informa- 
tion, which is shown above that strip. For 
example, if the combined status of operands 
2 and 3 is 1010 (reading downward), the bit 
strip below that status is to be used 
during code generation. (The status of 
operand 2 is indicated in the first two 
vertical positions, reading downward; the 
Status of operand 3 is indicated in the 
second two vertical positions, reading 
downward). The meanings of the various 
bit settings in each bit strip are as 
follows: 


0--The 
instruction 
as part 
sequence. 


associated skeleton array 
is not to be included 
of the machine code 


1--The associated skeleton array 
instruction is to be included as 
part of the machine code sequence. 


X--The associated skeleton instruc- 
tion may or may not be included as 
part of the machine code sequence, 
depending upon whether or not the 
associated base address is to be 


ee ee Te ee ST A HE A SD 


14In some cases, operand 3 does not exist 
and only the status of operand 2 is indi- 
cated. 


APPENDIX C: 


loaded, or wheth 
into operand i i 
(In some cases 


ARRAYS 


er or not a_ store 
s to be performed. 
, O*S rather than 


X's appear for base register loads 


and the | 
instruction.) 


subject store 


MINUS: Used for All Subtract Operations 
(cr tte a ara es aos Sara 1 
| | Skeleton | | 
| Index| Instructions | Status | 
f===5 {SSeS ese ee 
| | |0000000011111111| 
| | |0000111100001111 | 
| | |0011001100110011] 
| | |0101010101010101 | 
| | | | 
} 1 |u B2,D(0,BD) | XXXXXXXX00000000| 
} 2 {|LH R2,D(0,B2) |9000111100000000] 
| 3 |DH R1,D(X,B2) ]1100000000000000 | 
| 4 [L B3,D(0,BD) | XX0 OXXOOXX00XX00] 
} 5 |LCR_ R3,R3 }0010001000000010| 
| © |LR R1,R2 | 0000110100001101 | 
| 7 | R3,D(0,B3) |9100010001000100]| 
{| 8 |LCR R1,R3 10001000000000000| 
| 9 |SH R1,D(X,B3) |} 1000100010001000]| 
| 10 {SR k1,R3 }0100010101110101] 
{ 11 |AH R3,D(X,B2) }0010000000000000}| 
{ 12 |AH R1,D(X, B2) {0001000000000000| 
} i3 |AR R3,R2 {0000001000000010| 
j} 14 |[L B1,D(0, BD) | XXXXXXXXXXXXXXXX | 
| 15 {STH R1,D(0,B1) | XXXXXXXXXXXXXXXX | 
boces = ee nee ae ere ie ee Te Naat Mee ee 4 
NTFXGN: Used for the INT, IDINT, IFIX, and 
HFIX In-Line Routines 
canine SI aa acs arcana area 1 
| | { INT, | 
| | | IFiIx, | 
| | Skeleton | HFIX IDINT | 
| Index] Instructions {Status Status | 
f----- | Sa a ee ome aa s Seles omen sale ca { 
| | j 0011 0011 | 
| | | 0101 0101 | 
| | | | 
| 1 #|SDR 0,0 {} 1111 0000 | 
| 2 fL B2,D(0,BD) | XxX00 XX00- | 
{| 3 {Lo R2,D(0,B2) | 0100 0100 =| 
} 4 |LD 0,D(0,B2) | 1000 1000 | 
| 5 |LDR 0,R2 } 0111 0111 | 
| 6 |AW 0,60(0,12) { 1111 1111 | 
|} 7 |STD O,64(0,13) | 1111 1111 | 
{| 8 |L R1,68(0,13) | 1111 1111 | 
| 9 |BALR 15,0 } 1111 1111 | 
{ 10 {BC 10,6(0,15) | 1111 1111 =| 
} 11 |LNR- R1,R1 } 1111 1111 | 
{12 {L B1,D(0,BD) | XXXX XXXX | 
| 13 |STH R1,D(0,B1) | XXXX XXXX_ | 
eee arene 1 Ea eee ae dS a oe i ee 3 
Appendix C: Arrays 165 


ABSGEN: Used for the ABS, IABS and DABS 
In-Line Routines 

aa ema aa maa aa 5 aca aac as 1 
| | Skeleton | | 
| Index | Instructions | Status | 
[aaoeea = a an aa aac es ae Ra | 
| i | 0011 | 
| | | 0101 | 
| | | | 
i 1 | B2,D(0,BD) | xx0o~ | 
| 2 | LH R2,D(0,B2) | 1100 | 
| 3 | LPR R1,R2 | 1111 | 
| 4 | B1,D(0,BD) | XXXxX = | 
| 5 | STH R1,D(0,B1) | KXNE” | 
losacSes. see oh tee es Pec e ore es 4 
MOD24: Used for the MOD24 In-Line Routine 

(HSS oye Tao tes ee ae ee aman on ean ata 1 
| | Skeleton | | 
| Index | Instructions | Status | 
}--------- }-------------------- }---------- { 
| | | 0011 | 
| | | 0101 | 
| | | I 
| iL i B2,D(0, BD) | XxX00 | 
| 2 | 4. R2,D(X,B2) | 1100 | 
| 3 | LA R1,0(0,R2) | 1111 | 
| 4 { B1,D(0,BD) | xXXxx = | 
| 5 | st R1,D(0,B1) | XXXX | 
Loe See Banh iar hae an tenet oe ee me? 4 
MXMNGN: Used for the MAX2 and MIN2 In-Line 

Routines 

[--=>> Troe oo ee ee Gog a ee 1 
| | Skeleton | 

| Index | Instructions | Status | 
t----- }------------------ $---------------- 

| | }0000000011111111 | 
| | | 0000111100001111 | 
| | | 0011001100110011} 
| | {| 0101010101010101/| 
| | | | 
} 1 {[L B2,D(0,BD) | XXXXXXXX00000000| 
| 2 {LH R2,D(0, B2) | 0000111100000000j| 
} 3 |LH R1,D(0,B2) |} 1100000000000000] 
| 4 {CR R1,R2 | 0000001000000010]| 
{| 5 {CH R3,D(0,B2) {0001000000000000| 
{| 6 {CH R1,D(0,B2) | 0010000000000000 | 
| 7 {[L B3,D(0,BD) | XXOOXX00XX00XX00 | 
} 8 |LH R3,D(0,B3) {0100010001000100]| 
| 9 |CR R2,R3 {| 0100010101110101 | 
{| 10 |CH R2,D(0,B3) | 0000100000001000| 
{| 11 |CcH R1,D(0, B3) {| 1000000010000000| 
{ 12 |LR R1,R2 {9000110100001101 | 
{ 13 |LR R1,R3 | 0001000000000000| 
| 14 |BALR 15,0 {1111111111111111| 
{ 15 {Be N,6(0,15)2 j1111111111111111)] 
| 16 {LR R1,R2 | 0000001000000010| 
{| 17 |LR R1,R3 | 0100010101110101 | 
| 18 |L# R1,D(0, B2) | 0011000000000000| 
| 19 |LH  R1,D(0,B3) |1000100010001000] 
j} 20 |L B1,D(0, BD) | XXXXXXXXXXXXXXXX | 
j} 21 |STH R1,D(0,8B1) | XXXXXXXXXXXXXXXxX |] 
}----~- I Spates ance ne EEE TM ee I 4 
|*For MAX2,N=2; for MIN2,N=4. | 
Dede eer eee ee ee ee ee ee 3 


SHFTRL: Used for the SHFTR and SHFTL In- 
Line Routines 

Pace Poa ee ae Sa a alc esiuas calla 1 
| | Skeleton | | 
| Index| Instructions | Status i 
}--~-- +------------------ {~--~----~--—---- 
| | {0000000011111111] 
| | }0000111100001111| 
| | j0011001100110011 | 
| | {0101010101010101| 
| | | | 
} 1 |L B2,D(0,BD) | XXXXXXXX00000000| 
| 2 {tL R2,D2(X,B2) |1111111100000000| 
{ 3 |LR R1,R2 {0000111100001111 | 
} 4 4 |L B3,D(0,BD) | XXOOXXO0O0XX00XX00 | 
| 5 |LH R3,D3(X,B3) {|{1100110011001100| 
| 6 |SRL R1,0(0,R3) {1111111111111111 | 
| 7 {L B1,D(0,BD) | XXXXXXXXXXXXXXXxX | 
| 8 |ST  R1L,D(CO,B1) | XXXXXXXXXXXXXXXxX | 
eer Boose aoe Se ease eee eee pee J 
DBLGEN: Used for the DBLE In-Line Routines 
(era oe net ere et aa a 1 

| Skeleton | 
| Index | Instructions | Status | 
}--------- }------~------------- }---------- { 
| | | 0011 | 
| | | 0101 | 
| | | | 
| 1 } oL B2,D(0,BD) {| XX00 | 
| 2 {| SDR R1,R1 | 1111 | 
| 3 |} LER 0,R2 | 0010 | 
| 4 | Le R1,D(0,B2) | 1100 | 
| 5 j LER R2,R1 | 0100 | 
| 6 {| LDR R1,0 | 0610 | 
| 7 {| LER R1,R2 | 0001 | 
| 8 a B1,D(0,BD) | XXXX | 
| 9 | STD R1,D(0,B1) | XXXX | 
CSS Dea ee aoe eee ee beSeaoe == 4 
DIMGEN: Used for DIM and IDIM In-Line 

Routines 

eras: Pe oe a ge Tae Sr 1 
| | Skeleton | | 
| Index| Instructions | Status | 
}----- }~----------------- }~----~---------- 
| | }G6000000011111111 | 
| | |0000111100001111 | 
| | |0011001106116011 | 
| | |} 0101010101010101 | 
| | | | 
oe ee B2,D(0,BD) | XXXXXXXX00000000| 
{ 2 |LH R2,D(0,B2) |0000111100000000 | 
| 3 |LH R1,D(0,B2) }1101000000000000 | 
{ 4 |LCR- R1,R3 {0010001000000010 | 
| 5 |AH R1,D(0, B2) |}0010000000000000 | 
{} 6 |L B3,D(0,BD) | XXOOXXO0OXX00XX00| 
| 7 |LH R3,D(0,B3) {0100010001000100| 
| 8 |LR R1,R2 | 0000110100001101 | 
| 9 |SH R1,D(0,B3) |1000100010001000| 
{ 10 {AR R1,R2 }0000001000600010 | 
}| 11 |SR R1,R3 |0101010101110101]| 
| 12 |BALR 15,0 }1111111111111111 | 
{ 13 |Bc 10,6(0,15) }1111111111111111| 
{ 14 |SR R1,R1 }2111111111111111 | 
} 15  |L B1,D(0, BD) j XXXXXXXXXXXXXXxXxX | 
} 16 |STH R1,D(0,Bi) | XXXXXXXXXXXXXXXX| 
Loses Peete SSH SSs Se eet aa eS J 


SIGNGN: Used for SIGN, ISIGN, and DSIGN 
In-Line Routines 

ead PaaS ee ee aa la sea leas 1 
| | Skeleton | | 
| Index | Instructions | Status | 
}----- $~----------------- +---------------- 

| | |0000000011111111] 
| | {0000111100001111 | 
| | }0011001100110011] 
| | | 0101010101010101/] 
| | | I 
i 1 ([L B2,D(0,BD) | XXXXXXXX00000000 | 
| 2 |L#H R2,D(0,B2) {0000111100600000| 
| 3 JLTR- R3,R3 {0010001000100010| 
| 4 | R1,D(0,B2) | 1111000000000000| 
| 5 |L B3,D(0,BD) | XXOOXX00XX00XX00 | 
| 6 {LH R3,D(0,B3) | 0100010001000100| 
| 7 |LR R1,R2 {0000001000000010j 
{| 8 |LPR- R1,R2 | 0000110100001101)] 
{| 9 |LPR- R1,R1 | 1101000011010000] 
|} 10 |LTR_ R3,R3 {0101010101010101)] 
{11 |TM 128,D(0,B3) {1000100010001600]| 
| 12 {|BALR 15,0 }1111111111111111] 
| 13 |Bec 14,6(0,15) {1000100010001000| 
} 14 {Bc 10,6(0,15) | 0111011101110111)] 
} 15 |{LNR R1,R1 | 1111111111111111| 
{| 16 {BC 15,12(0,15) ]0010001000100010]| 
| 17 |LPR_ R1,R1i | 0010001000100010j 
j, 18 |L B1,D(0, BD) | XXXXXXXXXXXXXXXX | 
| 19 {STH R1,D(0,B1) Laie saaaccaciecnaeaaiaia 
ete tae ea Ae et a Se ee 

ADMDGN: Used for DMOD and AMOD In-Line 

Routines 

‘ora Gere ee So Poss ee eres 1 
| | Skeleton | | 
| Index | Instructions | Status | 
}-----}------------------ ¢---------------- 

| | }9000000011111111] 
| | {0000111100001111] 
| | ]0011001100110011]| 
| | | 0101010101010101| 
| i | | 
} 12 |L B2,D(0, BD) | XXXXXXXX00000000| 
{ 2 |LD R2,D(0,B2) }0000111100000000| 
| 3 Jib R1,D(0,B2) | 1111000000000000]| 
| {STD R1,Temp+ |done by ADMDGN |- 
; 4 |L B3,D(0,BD) | XXOOXX00XX00XX00 | 
{| 5 |Ld R3,D(0,B3) {0100010001000100 | 
{| 6 fLDR- R1,R2 | 0000111111111111 | 
} 7 |DDR R1,R3 | 0111011101110111/] 
| 8 |DD R1,D(0,B3) {1000100010001000]| 
| 9 JAD R1i,n(0,12) }1111111111111111| 
| 10 |MDR = R1,R3 |0111011101110111] 
} 11 |™MD R1,D(0,33) |1000100010001000| 
| 12 |LCDR R1,R1 ]}1111111111111111]| 
} 13 {AD R1,D(0,B2)+ {|1111111100000000| 
] 14 |ADR R1,R2 |0000000011111111 | 
} 15 |[L B1,D(0, BD) | XXXXXXXXXXXXXXXxX | 
} 16 |STD R1,D(0,B1) | XXXXXXXXXXXXXXXxX | 
bo—-=— SEI Recm ee ee Ma ae es Ue a haar tao ee een 

j+When the statuses and base address| 
| statuses of Operands 2 and 3 are zero, a| 
| store of operand 2 into a temporary wilil| 
| be done as indicated and the add will be| 
| from the temporary location. | 
Us ea A es eee ee J 


CMPLGN: Used for COMPL and LCOMPL In-Line 


Routines 

ania aioe a alata ae aan ee a TSS ee 1 
| i Skeleton | | 
| Index | Instructions } Status | 
Peasereeee qa SaS Sees = {eee seers | 
| | | 0011 | 
| | | 0101 | 
| | | 0000 | 
| | | 0000 | 
| | 
| 1 | L B2,D(0,BD)_ | XX00 | 
| 2 } 4. R2,D(0,B2) | 0100 | 
| 3 | LA R1,1(0,0) ] 1101 | 
| 4 | LCR R1,R1 i 1111 | 
| 5 oe 4 R1,D2(X,B2) | 1000 | 
| 6 | XR R1,R2 | 0101 | 
| 7 | BCTR R1,0 | 0010 | 
| 8 |} -L B1,D(0,BD) | XXXX | 
| 9 | st R1,D(0,B1) | XXXX | 
iene eae ee ee Be ati a fea Oe eel Foe 4 
LGLNOT: Used for NOT Operations 
aaa aa a a Mpa a poe eee ee eae {ers 2S Se 1 

{ Skeleton | | 
| Index | Instructions {| Status | 
pases Saale lem cae nade $---~------ { 
| | | 0011 | 
| | i 0101 | 
| | | | 
| 1 | L B2,D(0,BD) | XX00 | 
| 2 {} LA R1,1(0,0) | 1101 | 
| 3 | BCTR R1,0 | 0010 | 
| 4 | LCR  R1,R1 | 0010 | 
| 5 | XxX Ri,D(X,B2) | 1000 | 
| 6 | L R2,D2(0,B2) | 0100 j 
| 7 |} XR R1,R2 | 0101 | 
| 8 ae B1,D(O0,BL) | XXXX | 
| 9 | st R1,D(0,B1) | XXXX | 
one ona ee E Reaepcra erent a cetera ene $e ee 4 
BTBF: Used for All Branch True and Branch 

False Operations 
toe aa am laa aes Ts Se ree 1 
| | Skeleton | | 
| Index| Instructions | Status | 
[-----}----------------- }~-~-------------- { 
| | |0000000011111111 | 
| | }0000111100001111 | 
| | }0011001100110011 | 
| | {6101010101010101 | 
I | | | 
{ 1 |L B2,D(0,BD) {0000000000000000 | 
{ 2 |L R2,BD(0,B2) |1111111100000000 }| 
1 3 |SR R3,R3 {1100110011001100 | 
{ 4 {L B1,D(0,BD) [|1111111111111111 | 
{ 5S {|{BXH R2,0(R3,Bi) {1111111111111111+* | 
| 6 ieee R2,0(R3,B1) ieee 
basal 4s Se ee oh eee 
|*One =e these two eae will bej| 
Jadded to the bit strip by subroutine| 
ey depending on the operation. | 
a a rec gg ae ce a a oe ees J 
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LDADDR: Used for All Load Address Opera- 
tions 
(Sea Sea Arama Fos er eS 1 
| | Skeleton | | 
| Index| Instructions | Status | 
t----- }------------------ }~~--~----------- 
| | |} 9000000011111111 | 
| | | 0000111100001111} 
| | }0011001100110011 | 
| | }0101010101010101 | 
| | | | 
{| 2 |L B3,D(0, BD) | 0000000000000000 | 
| 2  |LH R3,D(0,B3) {1100110011001100 | 
| 3 |L B2,D(0, BD) | 0000000000000000| 
| 4 {LA R1,D(R3,B2) = |1111111111111111| 
1 5 |b B1,D(0, BD) | 0000000000000000| 
| 6 {st R1,D(0,B1) }1111111111111111 | 
| 7 [DA 0,128(0,0) | 9000000000000000 | 
{| 8 fMVI 128,D(0,B1) Oe poe tee Onc oee ee 
epee ron BN aa a ce a eae 
LDBGEN: Used for Ali Load Byte Operations 
aaa Te i ToaS Se ee 1 
| { Skeleton | | 
j Index | Instructions | Status | 
[----- }------------------} --------=-—--=-— 
| | }9000000011111111 | 
| i | 0000111100001111 | 
{ | | 0011001100110011 | 
| | |0101010101010101 | 
I \ | | 
| 2 |[L B3,D(0,BD) | 0000000000000000 | 
} 2 {SR R3,R3 |1111111100600000 | 
| 3 fie R3, D(X, B3) j2111111111111111 | 
1 4 |L B1,D(0, BD) |0000000000000000 | 
| 5 |stT R3,D(0, B1) pabooeesnodee 
bon Oe eae a het a as Sas eM a 
DIVGEN: Used for all dHalf-Word Integer 
Division Operations and for the 
MOD In-Line Routine 
aia De eee ae a aca 1 
| | Skeleton | | 
| Index| Instructions | Status | 
eee pecs et 
j | }0000000011111111 | 
| | |0000111100001111 | 
| | {| 0011001100110011| 
| | | 0101010101010101] 
| \ | | 
{ 1 |L B2,D(0, BD) | 0000000000000000| 
| 2 {LH R2,D(0,3B2) {0000111100000000| 
| 3 |LH R1,D(0,B2) ]11111000000000000| 
{ 4 |L B3,D(0, BD) | 0000000000000000 | 
| 5S |LH R3,D(X, B3) | 1100110011001100| 
| 6 LR R1,R2 | 0000111100001111 | 
| 7 |JSRDA R1,32(0,0) {1111111111111111 | 
i 8 |DR R1,R3 }1111111111111111]| 
| 9 fD R1,D(X,B3) | 0000000000000000 | 
} 10 |L B1,D(0,BD) | 0000000000000000| 
} 11 |STH R1+1,D(0,B1) |0000000000000000 | 
{| 12 |STH R1,D(0,B1)* penenooreuueonoe 
}-----1-----~------------1---------------- { 


SUBGEN: Used for Case 1 and Case 2 Sub- 
Script Operations 
foros TS eee 5 a aaa aa clan 1 
| | Skeleton | | 
| Index| Instructions | Status | 
b-===— Bette eee i Sean ere em Oe eae | 
| Case 1 | 
}----- EERE pore r perp 
| | 40000000011111111] 
| ] }0000111100001111 | 
| { {0011001100110011)] 
| | |}0101010101010101 | 
pon npn nnn ef 1 
{| 1  |L B3,D(0,BD) }0000000000000000] 
| 2 |LH R3,D(0, B3) |1100110000000000 | 
{ 3  [L B2,D(0, BD) {0000000000000000 | 
| 4 |LH R2,D(0,B2) }1111111100000000 | 
|} 5S ju B1,D(0,BD) |0000000000000000 | 
| 6 |STH R2,D(0,B1) regeuenecuoeeen) 
fom nnn hn nn { 
| Case 2 | 
foSeres 5 a ace aa Load gg a rio 
| | }0000000011111111 
| | {0000111100001111 | 
| | |0011001100110011 | 
| | j0101010101010101 | 
f----- fo----->---~ =~ ---- f--- === - =~ === 
| 12 |L B3,D(0, BD) |0000000000000000| 
| 2 |DLH R3,D(0,B3) {1100110011001100j| 
{| 3 |L B2,D(0,BD) |0000000000000000 | 
{| 4 |LH R2,D(0,B2) {0000000000000000 } 
| 5 |L Bi,D(0, BD) {0000000000000000 | 
| 6 {STH R2,D(0,B1) Suan epee auediea 
(2a. EUS atte ee ac seee neces nN eee as ee eS 
UNRGEN: Used for All Unary Minus Opera- 
tions 
eer a aa a a ec 2 aa aa a aa 1 
| | Skeleton | | 
| Index| Instructions | Status | 
f----- }------------------ }-------~-------- 
| | {0000000011111111)] 
| | |0000111100001111 | 
| | }0011001100110011 | 
| | {| 9101010101010101 | 
| | | | 
} 1 {[L B2,D(0,BD) {0000000000000000 | 
{ 2 {La R2,D2(X,B2) |1111111100000000| 
| 3 |LCR R1,R2 {2111111111111111] 
| 4 {BL B1,D(0, BD) |9000000000000000 | 
| 5S  |STH R1,D1(X,B1) pooper cneoeerorss | 
Eee ewe Be oath ar ieee e 
BRCOMP: Used for All Assigned GO TO Opera- 
tions 
=a 5 aa ce i i ea feos a a ee 1 
| 1 Skeleton | | 
| Index| Instructions | Status | 
}-----}--—-----—-------—- -----~--~--—~=-- 
| | }0000000011111111 | 
| | }0000111100001111] 
| | {}0011001100110011 | 
| | {0101010101010101 | 
| | | | 
| 2 |[L B2,D(0,BD) |9000000000000000| 
} 2 |L R2,D(0,B2) {1111111100000000 | 
{ 3 {BCR 15,R2 (te 
boot Ne at no ech ae eal a eee Sateae Paap a Lae et a 


INTMPY: Used for All Fixed Point Multi- 
piication Operations 
cS a a ml a ead a aa 1 
| | Skeleton | | 
| Index| Instructions | Status | 
f==o=5 slg aa a a Reeder lead fa deat gta 
| | {0000000011111111 | 
| | {}0000111100001111| 
| ] }0011001100110011 | 
| | |0101010101010101) 
| | | | 
{ 21 |[L B2,D(0,BD) {0000000000000000| 
| 2 |LH R2,D(0,B2) ]9000111100000000} 
| 3 |L8 R1,D(X,B2) }1100000000000000| 
{ 4 JL B3,D(0, BD) {0000000000000000| 
| 5 |La R3,D(0,B3) {0100010001000100}| 
| 6 |LR R1,R2 }C000110100001101| 
| 7 |LR R1,R3 | 0001 000000000000] 
| 8 |MR Ri-1,R3 }01000101G61110101] 
| 9 |MR R1-1,R2 }0000001000000010 | 
{ 10 |MH R1,D(X,B3) {1000100010001000j| 
| 12 |MH R1,D(X,B2) {0011000000000000| 
{ 12 |L B1,D(0,BD) {| 0000000000000000| 
{| 13 |STH R1,D(0,B1) |0000000000000000] 
bows fa ape a ee eee OR ee Oe opel ee ee J 
NDORGN: Used for the AND and OR In-Line 
Routines 
pres To. at ies 7 
| | Skeleton | | 
| Index| Instructions | Status | 
| ---~-}--------~--------- }~-~~--~---~---~- { 
| | }0000000011111111| 
| i {0000111100001111 | 
| ] | 0022901100110011 | 
| | }0101010! 3.010101] 
| | | | 
} 2 fk B2,D(0,BD) | O}OOODD0000000000 | 
| 2 |L R1,D(X,B2) {1111111111111111] 
| 3 {L B3,D(0, BD) |0000000000000000]| 
1 4 {IN R1,D(X,B3) }1111111111111111| 
{ 5 |L B1,D(0, BD) | 0000000000000000 | 
|} 6 |sT R1,D(0,B1) }1111111111111111| 
ieaoeeeree We el Or tae A Baas eee ea cr eC J 


SHFT2: Used for Ali Right- and Left-Shift 


BRCOMB: Used for All Computed GO TO Opera- 
tions 
(aS == ease ee esa Se ease eee 1 
| | Skeleton | | 
| Index | Instructions | Status | 
}----- {------------------ }---------------- 
| | |0000000011111111]| 
| | |0000111100001111] 
| | | 0011001100110011 | 
| | {0101010101010101 | 
| | | | 
{ 1 [BL B3,D(0, BD) ]|0000000000000000j 
{ 2 |L R3,D3(0,B3) |1100110011001100] 
{ 3 |LR R1,R3 }0101010101010101| 
| 4 |LA R2,P1 (0,0) [21111111111111111] 
| 5 |CLR R1,R2 }1111111111111111] 
| 6 |BALR R2,0 ]1111111111111111/] 
|} 7 |SLL R1,2(0,0) }1111111111111111] 
| 8 {BC  2,14(0,R2) }1111111111111111| 
|} 9 (|[L R2,D(R1,B) [1111111111111111] 
j 10 {BCR 15,R2 | 1111111111111111 | 
Loocin as ens ee Peo ose es ,) 
STRGEN: Used for All Store Operations 
cas Do a ee ae aaa re aa ar 1 
| | Skeleton | 
| Index | Instructions | Status | 
}-----}----------—-------}---~----~~--—--- 
| | |} 0000000011111111 | 
i | |0000111100001111| 
| | }0011001100110011] 
| | }0101010101010101] 
{ | | | 
|} i JL B2,D(0, BD) |0000000000000000 | 
|} 2 |La R2,D(0, B2) }1111111100001000j| 
{| 3 fu B1i,D(0, BD) | 0000000000000000 | 
| 4  |[STH R2,D(X,B1) {0000000000000000 | 
ee Bde aes ee Beene ety at Ren eh ee era 4 
FLTIGEN: Used for the FLOAT and DFLOAT 
In-Line Routines 
ieee are ToS te ee ee ac eas 1 
| Skeleton | | 
{| Index | Instructions | Status | 
}--------- }-------------------- +--~------- : 
| | 0011 | 
| | 0101 | 
| I | 
1 | .L B2,D(0,BD) | XX00 | 
2 | LH R2,D(0,B2) | 1100 | 
3 | Lp R1,60(0,12) | 1111 | 
4 | STD R1,72(0,13) | 1111 | 
5 {| LTR R2,R2 | 1111 | 
6 | BALR 15,0 | 1111 | 
7 | Bc 4,16(0,15) | 1111 | 
8 | st R2,76(0,13) | 1111 | 
9 | AD R1,72(0,13) | 1111 | 
10 | Bc 15,26(0,15) | 1111 | 
11 { LPR 0,R2 | 1111 | 
12 | st 0,76(0,13) | 1111 | 
13 { SD R1,72(0,13) | 1111 | 
14 | L B1,D(0,BD) | XXXX | 
15 | STD R1,D(0,B1i) | XXXX | 
eet este Loewe ee eae a a eee 


CO ee ee cee Oe ene Se OE eee ee eS ee SS ee oe 


Operations 
ema Tee oe eee a en ee 1 
| | Skeleton | | 
| Index| Instructions | Status | 
|-----}------------------ {~-~-—~~---~----- { 
| | }90000000011111111 | 
| | }0000111100001111] 
| | {0011001100110011 | 
| | {0101010101010101 | 
| | | | 
{ 1 |L B2,D(0,BD) {0000000000000000]| 
| 2 |LH R2,D(0,B2) |1111111100000000| 
| 3 [LR R1,R2 {| 9000111100001111] 
{| 4 |SRA_ R1,P3(0,0) [21211111111111111| 
| 5S {HDR R1,R2 | 0000000000000000| 
} 6 {|{L B1,D(0, BD) 10000000000000000] 
| 7 |STH R1,D(0,B1) | 0000000000000000 | 
a boos SosenScoseecewsS Sees pare pede ett dee ol J 
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DIVGEN: Used for all Full-Word Integer 
Division Operations and for the 
MOD In-Line Routine 
as ee ee es Ty S pe ae es 1 
| | Skeleton | | 
| Index | Instructions | Status | 
}----- }-------~----------}---------------- 
| | j 0000000011111111 | 
| | {}0000111100001111| 
| | | 0011001100110011)] 
| | | 0101010101010101]| 
| | | | 
} 12 fu B2,D(0, BD) | 0000000000000000 | 
| 2 |LH R2,D(0, B2) { 0000111100000000]| 
} 3 |LH R1,D(0, B2) | 1111000000000000] 
} 4 |[L B3,D(0, BD) | 0000000000000000j| 
|} 5 |LH R3,D(X, B3) | 0100010001000100]| 
} 6 [LR R1,R2 | 0000111100001111] 
| 7 |SRDA R1,32(0,0) ] 1111111111111111] 
{| 8 |DR R1,R3 }0111011101110111 | 
} 9 {D R1,D(X, B3) | 1000100010001000] 
|} 10 |L B1,D(0, BD) | 0000000000000000]| 
|] 11 |STH R1+1,D(0,B1) |0000000000000000| 
| 12 |STH R1,D(0,B1i)* hae aaah ae 
p---~- 4 nnd { 
|* For MOD in-line Ecce only. | 
Lo Sa ae ama Bee i ee ie J 
TSTSET: Used to Compare Operands Across a 
Relational Operator and Set the 
Result to True or False 
aa ya OE aa ToC Tee 1 
| | Skeleton | | 
| Index | Instructions | Status | 
foie oe Sol eS Stee ee ee Se eee 
: | | 0000000011111111 | 
| | }0000111100001111| 
| | | 0011001100110011j 
| | ] 0101010101010101] 
| | | | 
| 1 |L B2,D(0, BD) | 0000000000000000j 
| 2 |L8 R2,D(X, B2) | 1111111100000000j| 
1 3 |[L B3,D(0, BD) { 0000000000000000 | 
| 4 |LaH R3,D(0,B3) }0100010001000100]| 
{ 5 |cH R2,D(X, B3) | 1000100010001000j 
| 6 |CR R2,R3 {,0111011101110111| 
{| 7 |LA R1,1(0,0) }1111111111111111 | 
|} 8 |BALR 15,0 ]1121111111111111]| 
{| 9 |Be M,6(0,15) ]1111111111111111] 
| 10  |SR R1,R1 }1111111111111111| 
} 11 {L B1,D(0, BD) | 9000000000000000 | 
{ 12 |st R1,D(0,B1) Eye Op ee Oe een ee | 
L 
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LOGCL: Used for All Logical Operations 
oe Toco tec ee So rate ee 1 
| | Skeleton | | 
| Index | Instructions | Status | 
[===> (es SSeS eS SS Sere ee ee 
| | {0000000011111111 | 
| | | 0000111100001111 | 
| | }0011001100110011] 
| | |0101010101010101 | 
I | | | 
{ 12 |[L B2,D(0,BD) | 90000000000000000| 
| 2 {[L R2,D(0,B2) |0000111100000000| 
} 3 |[L R1,D2(0,B2) {|1101000000000000| 
1 4 |L B3,D(0,BD) |0000000000000000| 
{ 5S |L R3,D(0,B3) j}0100010001000100| 
| 6 |L R1,D3(X,B3) |0000100000001000| 
{| 7 |LR R1,R2 | 0000010100000101j 
| 8 {NR R1,R2 |} 0000101000001010| 
{| 9 |NR R1,R3 }0101010101110101] 
} 10 |N R1,D2(0,B2) |0010000000000000] 
| 11 |N R1,D3(X,B3) |1000000010000000| 
{ 12 |L B1i,D(0, BD) }9000000000000000| 
| 13 |st R1,D1(0,Bi) decent ueaees 
Loos ea a rh ieee et a ale 
PLSGEN: Used for Ali Addition Operations 
and for Real Multiplication and 
Division Operations 
Poon Get soe ee ee oe {os Se 1 
j Skeleton | 
| Index| Instructions | Status | 
------ $-- rn a fn err ee 
| | |0000000011111111| 
| | {0000111100001111 | 
| | | 0011001100110011 | 
| | {0101010101010101] 
| | | | 
|} 12 [ZL B2,D(0,BD) |0000000000000000| 
{ 2 |LH R2,D(0,B2) |6000111100000000]| 
{| 3 |LH R1,D(X,B2) }1101000000000000} 
; 4 |L B3,D(0,BD) |0000000000000000| 
| 5S [8 R3,D(0,B3) | 0100010001000100 | 
| 6 |LH R1,D(X,B3) |0000000000000000j| 
|} 7 |LR R1,R2 }0000110100001101] 
{| 8 |AR R1,R2 | 0000000000000000| 
| 9 JAR R1,R3 {0101010101110101] 
| 10 |AH  R1,D(X,B2) {| 0010000000000000 | 
| 11 |AB R1,D(X, B3) |1000100010001000| 
{} 12 |L B1,D(0,BD) {0000000000000000| 
| 13 {STH R1,D(0,B1) naa aeeemcnet neared ene 
p-—--—4--——-—- ~~ —- = t= == { 
| Note For real nuit pitestioa and divi-| 
jsion Operations, the basic operation| 


|codes will be replaced by the 


reeds: 


required | 


BRLGL: Used for Text Entries Whose Opera- BRLGL: Used for Text Entries Whose Opera- 
tor is a Relational Operator Oper- tor is a Relational Operator Oper- 
ating on Two Non-Zero Operands ating on One Operand and Zero. 

err Pep ee a ar a 1 ieogaaes Tors ee ee ; Saas ac aa a aa ace 7 

| | Skeleton | | | | Skeleton | | 

| Index | Instructions | Status | | Index| Instructions | Status | 

}----- ------------------}---------------- f---~- }---~--------------}-~-—- ~~ -------- 

| | }9000000011111111 | | | }0000000011111111] 

| | {0000111100001111] | | |0000111100001111 | 

| | | 0011001100110011 | | | }0011001100110011/| 
| | | 0101010101010101] | | | 0101010101010101 | 
| | | tf | | | 

{ 1 |L B2,D(0,BD) {9000000000000000 | { 2 |L B2,D(0,BD) | 0000060000000000 | 

| 2 |LH8 R2,D(0,B2) | 1111111100000000}| | 2 {LH R2,D(0,B2) }1111111100000000| 

| 3 | |[L B3,D(0,BD) | 0000000000000000| | 3  |L B3,D(0, BD) | 0000000000000000 | 

{ 4 | R3,D(X, B3) | 0100010001000100}| | 4 |LH R3,D(X,B3) | 9000000000000000 | 

|} 5S {cH R2,D(X,B3) |1000100010001000]| |} 5 |CH R2,D(X,B3) }0000000000000000] 

{| 6  |CR R2,R3 j{0111011101110111] | 6 [CR R2,R3 |0000000000000000| 

{ 7 |LTR R2,R2 | 0000000000000000j| } 7 |LTR R2,R2 {1111111111111111] 

| 8 |L R1,P1 }41111111111111111| | 8 |L R1,P1 }12211111111111111 | 

{| 9 {BCR M,RI1 }1111111111111111/| | 9 |BCR M,R1 {1111111111111111| 

 aeaeerereet ieee ga pn Ome eer ete fee een eden we arcane SpE ret J erate Looe ett oP ec Sen Ov Se ne Rees RE Sao 4 

LBITTF: Used for the LBIT, BBT, and BBF In-Line Routines 

Ry tere re es ape ay ee ey ecg a ae ie a ee Cee a Ce a eR ACTS a eg aaa 1 

| | i BBT, BBF 11 LBIT | 

a tera ar ee te ale ae ae ae ta | 

: Skeleton | Simple subscriptea || simple subscripted | 

{| Index | Instructions { variable variable {| variable variable | 

[--~~~-- }----~---~---——-- === === poe }}{-------------~------------ { 

| 1 { L B2,D(0,BD) l Xx X | X X | 

| 2 | LA 15,D+N/8(X,B2) | 0 1 1 | 0 1 | 

l 3 | TM M, D#tN/8 (B2) | 1 0 {1 8 0 | 

| 4 {| TM M,0(15) | 0 1 | | 0 1 | 

| 5 { TM M, D#tN/8 (R2) | 0 0 1 | 0 0 | 
| 6 j L 15,P1 | 1 1 i | 0 0 | 
| 7 | BCR MM,15 | 1 1 l | 0 0 | 
| 8 | BALR 15,0 | 0 0 i] 1 1 | 
| 9 | LA R1,1(0,0) | 0 0 1] ai 1 | 
| 10 | Bc 1,10(0,15) | 0 0 | | 1 1 | 

{ 11 { SR R1,R1 | 0 0 | 1 1 | 

} 12 | L B1,D(0,BD) | 0 0 i] X xX | 

{ 13 | stv R1,D(0,B1) | 0 0 1] X X | 

bosons ee ipsa iit eel yy A pr a ge eer 5 [ARE oye re en EN er ese ao SEE | 

| N = The bit to be loaded or tested. | 
| | 
| M = MSKTBL(MOD(N,8)+1). MSKTBL is an array of masks used by LBITTF. | 
| | 
| MM = 1 FOR BBT. | 

| 

! MM = 8 FOR BBF. | 

ae ne PR ON A ey pa pe Om rp NE PE ry pee oS a da arg 7 a J 
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APPENDIX D: TEXT OPTIMIZATION EXAMPLES 


This appendix contains examples that illustrate the effects of text optimization on 
sample text entry sequences. An example is presented for each of the five sections of 
text optimization. 


Example 1: Common Expression Elimination 
This example illustrates the concept of common expression elimination. The text 


entries in block A are to undergo common expression elimination. Block B is aé_= back 
dominator of biock A. Block B contains text entries that are common to those in block A. 


Unchanged Unchanged 


(1) 
Block B 

















Eliminate Eliminate 
a3 RENT A Dos =1* 4 _ _W=JjJ*l2 J* 12 
A A 
T7=1* 4 
T8=J* 12 T38=J* 12 
T9 = 17+ T8 T9=T1+ T8 T9=T1+T2 
T10 = X (s T9 T10 =X (s T9 T10 =X (s T9 
B=TI0+2Z B=T10+Z B=TI0+Z 
(4) (5) 


Unchanged Unchanged 


Eliminate 
T10 = X (s T3 


Eliminate 
T9=T1+T2 


T10 = X (s T3 
B=T10+Z 





NOTE: The items Ti are temporaries and (s represents a subscript operator 
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Example 2: Forward Movement 


This example illustrates both methods of forward movement. Block A, containing 


the text entries to be moved, is a back dominator of the forward target of the loop, 
which is block B. 


(1) (2) 
Block A A 


Tl=A+B 
12=TI+C 


C=E+F 
Move T2=T1+C 






Move (note generated 
Q=T2+D text entry) 
Block B 
(4) 
Move 
TI=A+B 


T2=T14+Tj 
Q=T2+D 





NOTE: The text entry C = E + F cannot be moved, because operand 1 
(C) is used elsewhere in the loop 
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Example 3: Backward Movement 


This example illustrates both methods of backward movement. 


block A are to undergo backward movement. 
containing block A. 


Block B is the back target of the 


(1) 


Block B 


Move 
T2=T1+C 


X=E+U 


T2=T1+C 
E=12+D 





(4) 





FaW+Z 






TI=A+B 
T2=T1+C Move the 
expression 


™T™2+D 





NOTE: The text entry X = E + U cannot be moved, because its operand 2 is 
defined elsewhere in the loop. The text entry E = T2 + D cannot be 
moved, because operand 1 (E) is busy-on-exit from the back target; 
however, the expression T2 + D can be moved. 


Appendix D: 


Text Optimization Examples 


The text entries in 
Loop 
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Example 3*: Simple-Store Elimination 


The following example illustrates the concept of simple-store elimination, an 
integral part of the processing of backward movement. Note that the characteristics 
of the operands of the simple store correspond to the last combination of 
characteristics stated in Table 4. 





r 1 
| | 
| | 
| | 
| | 
| ee | 
| pre agee Ocul te | 
| Z=X A=X+B | 
| A=Z+B D=F*X | 
| D=F*Z Eliminate Z = X X=2*M | 
X=2*M ZaVVA 
! Z=Y/4 ae | 
| | 
| | 
| | 
| | 
| i 
| | 
p-----~-- 2 ~~ - 2 nnn nnn nnn nnn nnn nnn { 
| Note: Uses of operand 1 of the simple store that appear below the redefinition of | 
| either operand of the simple store are not replaced. | 
Ms a a hg gs er 4 
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Example 4: Strength Reduction 


This example illustrates both methods of strength reduction. In the example, 
strength reduction is applied to a DO loop. The evolution of the text entries that 
represent the DO 1100p, and the functions of these text entries are also shown. The 
formats of the text entries in all cases are not exact. They are presented in this 
manner to facilitate understanding. 


Consider the DO loop: 


I=3 


DO 10 J=1,3 
=X(I,J) 
10 CONTINUE 


AS a result of the processing of phases 10 and 15, and backward movement, the DO loop 


has been 


converted to the following text representation. 


PSSnea sarees Sc a ala ae Sal hans oe SS aS Sa er 
| Text Entry | Function | Evolution | 
poe seroe Ses ase= Sasa ie aaa lag at aa eaaas Ca : SSE Tisaaegearas acts caer v mci mies uae sali 5 Sa RSRaT cae ecaia as { 
| I = 3 J Initializes I {Stated in source module, converted to| 
| ] |phase 10 text and then to phase 15] 
| | Jtext. It resided in the back target of| 
{ | Jthe loop because of text blocking. | 
| I | | 
| J=1 {initializes J ]|Generated phase 10 text entry, converted | 

Back | | jto phase 15 text entry. It resided in the| 

Target | | |back target of the ioop because of text| 
| | | blocking. | 
| | 
| Tl=1* 4 {|Multiplies first [Generated by phase 15 when it encounters 
| [subscript parameter |the subscript parameter I during its pro-| 
| | by its dimension {cessing of phase 10 text. It resides in | 
| | factor Jtne back target of the loop as ae result] 
| | jof the processing of backward movement. | 
pom nm nnn nn nnn nnn nnn nnn nnn nf nn nn nnn nan nnn { 
Y T2 = 9 * 12 |Mulitiplies second {Generated by phase 15 when it encounters | 

|subscript parameter |the subscript parameter J during its pro-| 
| by its dimension |cessing of phase 10 text. 
| factor. | 


en ae 


T3 = T1 + T2 |Computes index value|Generated by phase 15 after the last sub- 
| for the subscripted |script parameter in the phase 10 text 
[variable X. |representation of the subscripted varia- 
[ble has been processed. 


| 
Stores X(I,J) into A|The phase 10 text entry forced and con-| 


| 

| 

A=xX (sT3 | 
| {verted to phase 15 text after the index] 
| [value for the subscripted variable has| 
| |been established. | 
{ | 
J=dg#ti | Increments DO index.|Generated by phase 10 and converted to| 
| {phase 15 text representation. | 
I | | 
IF(J<3)GOTO Y|Tests DO index [Generated by phase 10 and converted to | 
Jagainst its maximum |phase 15 text representation. | 
jand controls branch-| | 
. Jing. | | 
eas 5 tae Opa tA Me ea rh hs hk ye 


{|Note: The statement number Y is generated by phase 10. Also, it is assumed| 
jthat the array X is of the form X(3,3) and that its elements are real (length] 
4). | 
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The following figure illustrates the application of strength reduction to the loop. 


(1) 






Eliminate 
Additive 
Text from Loop 


Eliminate 
Multiplicative 
Text from Loop 






Y 1T2=J* 12 
T3 = 71 +72 
A=X (s T3 
Jj=J+1 
IF JS 3) GOTOY 


YT3=TI+M 
A=X (6 T3 
M=M-+4+ 12 
IF (MS 36) GOTOY 


YA=X(sP 
P=P+12 
IF (PSN) GOTOY 
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This appendix describes the Ilcgic of 
some of the object-time library subprograms 
that may be referenced by the FORTRAN load 
module. Included at the end of this appen- 
dix are flowcharts that describe the logic 
of the subprograms. 


Each object module, compiled from a 
FORTRAN source module, must be first proc- 
essed by the linkage editor prior to execu- 
tion on the IBM System/360. The linkage 
editor must combine certain FORTRAN library 
subprograms with the cbject module to form 
an executable load module. The library 
subprograms exist aS separate load modules 
on the FORTRAN system library 
(SYS1.FORTLIB). Each library subprogram 
that is externally referenced by the object 
module is included in the load module by 
the linkage editor. Among the library 
subprograms that may be so referenced are: 


e IHCFCOMH (Object-time I/O source state- 
ment processor) - entry name IBCOM#. 


e IHCFIOSH (Object-time sSsequentiai access 


I/O data management interface) - entry 
name FIOCS#. 

e THCNAMEL (object-time namelist 
routines) - entry names FRDNL# and 
FWRNL# 

e IHCDIOSH+ (Object-time direct access 
I/O data management interface) - entry 


name DIOCS#. 


e IHCIBERH (Object-time source statement 
error processor) - entry name IBERH#. 

e ITHCFCVTH (object-time conversion 
routine) 


e IHCDBUG+ (object-time Debug Facility 
support routine) - entry name DEBUG#. 


IHCFCOMH receives I/O requests from the 
FORTRAN load module via compiler-generated 
calling sequences. IHCFCOMH, in turn, sub- 
mits these requests to the appropriate data 
management interface (IHCFIOSH or 
THCDIOSH). 


4Although the FORTRAN IV (H) compiler does 
not yet have the code generation facilities 
for direct access and DEBUG statements, 
discussions of IHCDIOSH and IHCDBUG are 
included to describe the routines that will 
be used to perform object time implementa- 
tion of these statements when these facili- 
ties are incorporated into the compiier. 


Appendix E: 


APPENDIX E: OBJECT-TIME LIBRARY SUBPROGRAMS 


IHCFIOSH receives sequential access 
input/output requests from IHCFCOMH and, in 
turn, subinits those requests to the 
appropriate BSAM (basic sequential access 
method) routines for execution. 


LTHCDIOSH receives Girect access 
input/output requests from IHCFCOMH and, in 
turn, submits those requests to the 
appropriate BDAM (basic direct access 


method) routines for execution. 


If source statement errors are detected 
during compilation, the compiler generates 
a calling sequence to the IHCIBERH subpro- 
gram. IHCIBERH processes object-time 
errors resulting from improperly codea 
source statements. IHCFCVTH contains the 
varicus object time conversion routines 
required by IHCFCOMH and IHCNAMEL. 


IHCFCOMH 
IHCFCOMH performs object-time 


tation of the following 
Statements. 


implemen- 
FORTRAN source 


* READ and WRITE (for sequential I/O). 


e READ, FIND, and WRITE (for direct 
access I/0). 
® BACKSPACE, REWIND, and ENDFILE 


(sequentiai I/O device manipulation). 


e STOP and PAUSE (write-to-operator). 
In addition, IHCFCOMH: (1) processes 
object-time errors detected by various FOR- 
“TRAN library subprograms, (2) processes 
arithmetic-type program interruptions, and 
(3) terminates load module execution. 


All linkages from the load module to 
IHCFCOMH are compiler generated. Each time 
one of the above-mentioned source state- 
ments is encountered during compilation, 
the appropriate calling sequence to 
IHCFCOMH is generated and is included as 
part of the object module. At obdject-time, 
these calling sequences are executed, and 
control is passed to IHCFCOMH to perform 
the specified operation. 


Note: IHCFCOMH itself does not perform the 
actual reading from or writing onto data 
sets. It supmits requests for such opera- 
tions to the appropriate I/O data manage- 


ment interface (IHCFIOSH or IHCDIOSH). The 
I/O interface, in turn, interprets and 
submits the requests to the appropriate 
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access method (BSAM or BDAM) routines for 
execution. Figure 59 illustrates the rela- 
tionship between IHCFCOMH and the I/O data 
management interfaces. 


Charts 24, 25, and 26 illustrate the 
overall logic and the relationship among 
the routines of IHCFCOMH. Table 33, the 
IHCFCOMH routine directory, lists the rou- 
tines used in IHCFCOMH and their functions. 


4 
| FORTRAN | 
| Load | 
| Module | 


Lv +, 4 


| 

| 

1/0 | 
Request | 
| 

| 


amare ae Sse 

| IHCFCOMH | | IHCFCVTH | 

| (Determine }--{Conversion| 
| 


|Request type) | Routines | 
Lope seeee = got tees Heo 4 
| 
| | 
Submit | | Submit 
Sequential | | Direct 
Access 1/0 | | Access I/0 
Request to | | Request to 
THCFIOSH | | IHCDIOSH 
| | 
| 
SSeS sos Se 1 ay eee eee 
| IHCFIOSH | | THCDIOSH | 
| (Sequential | | (Direct | 
| Access I/O | | Access I/O | 
| Interface) | | Interface) | 
anes eee ee o-Sce 4 toca 8 eee eee J 
| i 
| | 
Interpret | | Interpret 
And submit | j And submit 
Request to | | Request to 
Appropriate | | Appropriate 
BSAM Routine| | BSAM/BDAM 
| | Routine 
| | 
por oS= fanSr= 7 (== Hs anes aie 2 
{| BSAM i | BSAM/BDAM | 
} Routines | {| Routines | 
bee Jj Bee ee 4 
Figure 59. Relationship Between IHCFCOMH 
and I/O Data Management Inter- 
faces 
The routines of IHCFCOMH are divided 


into the following categories: 
e Read/write routines. 


e I/O device manipulation routines. 
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e Write-to-operator routines. 
® Utility routines. 


The read/write routines implement both 
the sequential I/O statements (READ and 
WRITE) and the direct access I/O statements 
(READ, FIND, and WRITE). (The direct 
access FIND statement is treated as a READ 
statement without fornat and list.) 


The I/0 device manipulation routines 
implement the BACKSPACE, REWIND, and END 
FILE source statements for sequential data 
sets. These statements are ignored for 
direct access data sets. 


The write-to-operator routines implement 
tne STOP and PAUSE source statements. 


The utility routines: (1) process errors 
detected by FORTRAN library subprograms, 
(2) process arithmetic-type program inter- 
rupts, and (3) terminate load module execu- 
tion. 


READ/WRITE ROUTINES 


The READ/WRITE routines of IHCFCOMH 
implement the various types of READ/WRITE 
Statements of the FORTRAN IV language. For 
Simplicity, the discussion of these rou- 
tines is divided into two parts: 


e READ/WRITE 
LIistT. 


Statements not using NAME- 


e READ/WRITE statements using NAMELIST. 


READ/WRITE Statements Not Using NAMELIST 


For the implementation of both sequen- 


tial and direct access READ and WRITE 
statements, the read/write routines of 
IHCFCOMH consist of the following three 
sections: 


e An opening section, which initializes 
data sets for reading and writing. 


e An I/O list section, which transfers 
data from an input buffer to the I/0 
list items or from the I/O list items 
to an output buffer. 


® A closing section, which terminates the 
I/O operation. 


Within the discussion of each section, a 
read/write operation is treated in one of 
two ways: 


°® AS a read/write requiring a format. 


e As a read/write not requiring a format. 


Note: In the following discussion, the 





term “read operation" implies both the 
sequential access READ statement and the 
@irect access READ and FIND statements. 


The term “write operation" implies both the 
sequential access WRITE statement anda the 
direct access WRITE statement. 


OPENING SECTION: 
calling 
points in 


The compiler generates a 
sequence to one of four entry 
the opening section of IHCFCOMH 
each time it encounters a READ or WRITE 
statement in the FORTRAN’ source module. 
These entry points correspond to the opera- 
tions of read or write, requiring or not 
requiring a format. 


Read/Write Requiring a Format: If the 
operation is a read requiring a format, the 
opening section passes control to the 
appropriate I/O data management interface 
to initialize the unit number specified in 
the READ statement for reading. (The unit 
number is passed, as an argument, to the 
opening section via the calling sequence.) 
The I/O interface: (1) opens the data 
control block (via the OPEN 
macro-instruction) for the specified data 
set if it was not previously Opened, and 
(2) reads a record (via the READ 
macro-instruction) containing data for the 
I/O list items into an I/O buffer that was 
obtained when the data control block was 
opened. The I/O interface then returns 
control to the opening section of IHCFCOMH. 
The address of the buffer and the length of 
the record read are passed to IHCFCOMH by 
the I/0 interface. These vaiues are saved 
for the I/O iist section of IHCFCOMH. The 
opening section then passes control to a 
portion of IHCFCOMH that scans the FORMAT 
Statement specified in the READ statement. 
(The address of the FORMAT statement is 
passed, aS an argument, to the opening 
section via the calling sequence.) The 
first format code (either a control or 
conversion type) is then obtained. 

For control type codes (e.g., an H 
format code or a group count), an I/O list 
item is not required. Control passes to 
the routine associated with the control 
code under consideration to perform the 
indicated operation. Control then returns 
to the scan portion, and the next format 
code is obtained. This process is repeated 
until either the end of the FORMAT state- 
ment or the first conversion code is 
encountered. 


For conversion type codes (e.g., an I 
format code), an I/O list item is required. 
Upon the first encounter of a conversion 
code in the scan of the FORMAT statement, 
the opening section completes its process- 
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ing of a read requiring a format anc 
returns control to the next sequential 
instruction within the load nodule. 

Tne action taken by IHCFCOMK when the 


various format codes are encountered is 


illustrated in Table 28. 


If the operation is a write requiring a 
format, the opening section passes control 
to the I/O interface to initialize the unit 
number specified in the WRITE statement for 
writing. (The unit number is passed, as an 
argument, to the opening section via the 
calling sequence.) The I/O interface opens 
the data control block (via the OPEN 
macro-instruction) for the specified data 
set if it was not previously opened. The 
I/O interface then returns control to the 
opening section of IHCFCOMH. The address 
of an I/O buffer that was obtained when the 
data control block was opened is saved for 
the I/O list section of IHCFCOMH. ‘Subse- 
quent opening section processing, starting 
with the scan of the FORMAT statement, is 


the same as that described for a read 
requiring a format. 
Read/Write Not Requiring a Format: If the 


operation is a read or write not requiring 
a format, the opening section processing 
except for the scan of the FORMAT statement 
is the same as that described for a read or 
write requiring a format. (For a read or 
write not requiring a format, there is no 
FORMAT statement.) 


I/O LIST SECTION: The compiler generates a 
calling sequence to one of four entry 
points in the 1/0 list section of IHCFCOMH 
each time it encounters an I/O list item 
associated with the READ or WRITE statement 
under consideration. These entry points 
correspond to a variable or an array list 
item for a read and write, requiring or not 
requiring a format. The I/O list section 
performs the actual transfer cf data from: 
(1) an input buffer to the list items if a 


READ statement is being implemented, or (2) 
the list items to an output buffer if a 
WRITE statement is being implemented. In 


the case of a read or write requiring a 
format, the data must be converted before 
it is transferred. 


Read/Write Requiring a Format: In process- 
ing a list item for a read requiring a 


format, the I/O list section passes control 
to the conversion routine associated with 
the conversion code for the list item. 
(The appropriate conversion routine is de- 
termined by the portion of IHCFCOMH that 
scans the FORMAT statement associated with 


the READ statement. The selection of the 
conversion routine depends on the conver- 
sion code of the list item being 


processed.) 
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Table 28. IHCFCOMH FORMAT Code Processing 


3 


3 
rd 


is} 
a 


|Description | Type 
| | 
}-------------- }--------- 
|beginning of |control 
| statement | 
i 
| 
group count | control 
| 
| 
| 
field count | control 
| 
| 
| 


column reset 


skip or blank 


*‘text" or nHjliteral data 


“ow. alm ee” ap ge age eg ee 
3 
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NEO PHO A 
' 


group end 


record end 


end of 
statement 


fe mee re ces eee ce es ee ee AY SR SS ED ES a EE SS A NN ED SS ED SS ES AE GN AS eS SO eS SE Ee ee 


scaling factor|control 


control 


control 


control 


- conversion|conversion|Exit to the load module to return control to 

- conversion|conversion|entries FIOLF or FIOAF in IHCFCVTH. Using in- 
~ conversion|conversion|formation passed to the I/O list section, the| 
- conversion|conversion|address and length of the current list item are | 
conversion|conversion|obtained and passed to the proper conversion| 
- conversion|conversion|routine together with the current position in] 
- conversion|conversion|the I/O buffer, the scale factor, and the values| 
- conversion|conversion|of wandd. Upon return from the conversion | 


control 


control 


control 


Fr me ee ee ee ee eee eee cee Se ee ED Re ED ee ee ce SD nS SES eee 


{Save location for possible repetition of the 
|format codes; clear counters. 


{Save n and location of left parenthesis for 
jpossible repetition of the format codes in the 
| group. 

| 

| 


{Save n for repetition of format code which 
| follows. 


Save n for use by F, E, and D conversions. 


{Reset current position within record to nth 
|column or byte. 


{Skip n characters of an input record or insert n 
|blanks in an output record. 


{Move n characters from an input record to the 
{FORMAT statement, or n characters from the 
| FORMAT statement to an output record. 


{routine the current field count is tested. If| 
Jit is greater than 1, another exit is made to] 
jthe load module to obtain the address of the| 
jnext list item. | 
| | 
| | 
|Test group count. If greater than 1, repeat| 
j|format codes in group; otherwise continue to] 
{process FORMAT statement from current position. | 


| 
jinput or output one record via I/O Interface| 
jand READ/WRITE macro-instruction. | 
| 
| 
| 


|If no I/O list items remain to be transmitted, 
{return control to the load module to link to the] 
Jclosing section; if list items remain, input or| 
joutput one record using I/O interface and READ/| 
{WRITE macro-instruction. Repeat format codes| 
|from last parenthesis. i 


t 
I 
| 
| 
t 
I 
| 
! 
| 
{ 
ke 
I 
| 
{ 
{ 
| 
1 
' 
| 
{ 
| 
| 
| 
| 
| 
{ 
I 
| 
{ 
I 
| 
| 
| 
{ 
l 
| 
| 
| 
| 
\ 
{ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
I 
| 
| 
{ 
| 
| 
| 
lo 


The selected conversion routine obtains 
data from an input buffer and converts’ the 
data to the form dictated by the conversion 
code. The converted data is then moved 
into the main storage address assigned to 
the list item. 


after a conversion routine 
has processed a list item, the I/O list 
section determines if that routine can be 
applied to the next list item or array 
element (if an array is being processed). 
The I/O list section examines a field count 
that indicates the number of times a par- 
ticular conversion code is to be applied to 
succesSive list items or successive ele- 
ments of an array. 


In general, 


If the conversion code is to be repeated 
and if the previous list item was a varia- 
ble, the I/O list section returns control 
to the load module. The load module again 
branches to the I/O list section and pass- 
es, aS an argument, the main storage 
address assigned to the next list item. 


The conversion routine 
the previous 


that processed 
list item is then given con- 


trol. This procedure is repeated until 
either the field count is exhausted or the 
input data for the READ statement is 
exhausted. 


If the conversion code is to be repeated 
and if an array is being processed, the I/0 
list section computes the main storage 
address of the next element in the array. 
The conversion routine that processed the 
previous element is then given control. 
This procedure is repeated until either all 
the array elements associated with a spe- 
cific conversion code are processed or the 
input data for the READ statement is 
exhausted. 


If the conversion code is not to be 
repeated, control is passed to the scan 
portion of IHCFCOMH to continue the scan of 
the FORMAT statement. If the scan portion 
determines that a group of conversion codes 
is to be repeated, the conversion routines 
corresponding to those codes are applied to 
the next portion of the input data. This 
procedure is repeated until either the 
group count is exhausted or the input data 
for the READ statement is exhausted. 


If a group of conversion codes is not to 
be repeated and if the end of the FORMAT 
statement is not encountered, the next 
format code is obtained. For a control 
type code, control is passed to the asso- 
ciate@ control routine to perform the indi- 


argument, the main storage address assigned 
to the next list item. Control is’ then 
passed to the conversion routine associated 
with the new conversion code. The conver- 
sion routine then processes the data for 
this list item. If the data that was just 
converted was placed into an element of an 
array and if the entire array has not been 
filled, the I/O list section computes’ the 
main storage address of the next element in 
the array and passes control to the conver- 
Sion routine associated with the new con- 
version code. The conversion routine then 
processes the data for this array element. 
Subsequent I/O list processing for a READ 
requiring a format proceeds at the point 
where the field count is examined. 


If the scan portion encounters the end 
of the FORMAT statement and if all the list 
items are satisfied, control returns to the 
next sequential instruction within the load 
module. This instruction (part of the 
caliing sequence to IHCFCOMH) branches’ to 
the closing section. If all the list items 
are not satisfied, control is passed to the 
I/O interface to read (via the READ 
macro-instruction) the next input record. 
The conversion codes starting from the last 
left parenthesis are then repeated for the 
remaining list items. 


If the operation is a write requiring a 
format, the I/O list section processing is 


Similar to that for a read requiring a 
format. The main difference is that the 
conversion routines obtain data from the 


main storage addresses assigned to the list 
items rather than from an input buffer. 
The converted data is then transferred to 
an output buffer. If all the list items 
have not been converted and transferred 
prior to the encounter of the end-of-the 
FORMAT statement, control is passed to the 
I/O interface. The I/0 interface writes 
(via the WRITE macro-instruction) the con- 
tents of the current output buffer onto the 
output data set. The conversion codes 
Starting from the last left parenthesis are 
then repeated for the remaining list items. 


Read/Write Not Requiring a Format: In 
processing a list item for a read not 


requiring a format, the I/O list section 
must know the main storage address assigned 
to the list item and the size of the list 
item. Their values are passed, as argu- 
ments, via the calling sequence to the I/0 
list section. The list item may be either 
a variable or an array. In either case, 
the number of bytes specified by the size 
of the list item is moved from the input 
buffer to the main storage address assigned 





__... cated operation. ..._For _a—__conversion type 


+to—the--list —_item. The I/O list section 


code, control is returned to the load then returns control to the load module. 
module if the previous list item was a The load module again branches to the I/0 
variable. The load module again branches list section and passes, as arguments, the 
to the I/O list section and passes, aS an main storage address assigned to the next 
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list item and the size of the list item. 
The I/O list section moves the number of 
bytes specified by the size of the list 
item into the main storage address assigned 
to this list item. This procedure is 
repeated either until all the list items 
are satisfied or until the input data is 
exhausted. Control is then returned to the 
load module. 


If the operation is a write not requir- 
ing a format, the I/O list section process- 
ing is similar to that described for a read 
not reguiring a format. The main differ- 
ence is that the data is obtained from the 
main storage addresses assigned to the list 
items and is then moved to an output 
buffer. 


CLOSING SECTION: The compiler generates a 
calling sequence to one of two entry points 
in the closing section of IHCFCOMH each 
time it encounters the end of a READ or 
WRITE statement in the FORTRAN source 
module. The entry points correspond to the 
operations of read and write, requiring or 
not requiring a format. 


Read/Write Requiring a Format: If the 
operation is a read requiring a format, the 


closing section simply returns control to 
the load module to continue load module 
execution. If the operation is a write 
requiring a format, the closing section 
branches to the I/O interface. The 1/0 
interface writes (via the WRITE 
macro-instruction) the contents of the cur- 
rent I/O buffer (the final record) onto the 
output data set. The I/O interface then 
returns control to the closing section. 
The closing section, in turn, returns con- 
trol to the load module to continue load 
module execution. 


Read/Write Not Requiring a Format: If the 


operation is a read not requiring a format, 
the closing section branches to the I/0 
interface. The I/0 interface reads (via 
the READ macro-instruction) successive 
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records until the end of the logical record 
being read is encountered. (A FORTRAN 
logical record consists of all the records 
necessary to contain the I/O list items for 
a WRITE statement not requiring a format.) 
When the I/O interface recognizes the end- 


of-logical- record indicator, control is 
returned to the closing’ section. The 
closing section, in turn, returns control 


to the load module to continue load module 
execution. 


If the operation is a write not requir- 
ing a format, the closing section inserts: 
(1) the record count (i.e., the number of 
records in the logical record) into the 
control word of the I/0 buffer to ke 
written, and (2) an end-of-logical-record 
indicator into the last record of the I/0 
buffer being written. The closing section 
then branches to the I/O interface. The 
I/0 interface writes (via the WRITE 
macro-instruction) the contents of this I/0 
buffer onto the output data set. The I/0 
interface then returns control to the clos- 
ing section. The closing section, in turn, 
returns control to the load module to 
continue load module execution. 


Examples of IHCFCOMH READ/WRITE Statement 
Processing 


The following examples illustrate the 
opening section, I/0 list section, and 
closing section processing performed by 
IHCFCOMH for sequential access READ and 
WRITE statements, requiring or not requir- 
ing a format. 


Note: IHCFCOMH processing for the direct 
access READ, FIND, and WRITE statements is 
essentially the same as that described for 
the sequential access READ and WRITE state- 
ments. The main difference is that for 
direct access statements, IHCFCOMH branches 
to the direct access 1/0 interface 
(IHCDIOSH) instead of to the sequential 
access I/0 interface (IHCFIOSH). 


READ REQUIRING A FORMAT: 
performed by IHCFCOMH for 
READ statement and FORMAT 
illustrated in Table 29. 


The processing 
the following 
statement is 


READ (1,2) A,B,C 
2 FORMAT (3F12.6) 


Table 29. IHCFCOMH Processing for a READ 
Requiring a Format 

Se Sr or ae a CR ee ee 1 
|Opening |1. Receives control from load | 


WRITE REQUIRING A FORMAT: The processing 
performed by IHCFCOMH for the foliowing 
WRITE statement and FORMAT statement is 
illustrated in Table 30. 


WRITE (3,2) (D(I),1I=1,3) 
2 FORMAT (3F12.6) 


Table 30. IHCFCOMH Processing fora 


Requiring a Format 


WRITE 


|Section | module and branches to| f-------- Yor 1 
| | IHCFIOSH to initialize data] JOpening |1.. Receives control from load | 
| | set for reading. | |Section | module and branches to| 
| | | | | IHCFIOSH to initialize data| 
| j2. Passes control to scan por-| | | set for writing. | 
| | tion of IHCFCOMH. | | | | 
| i | | j2. Passes control to scan por-| 
| {3. Returns control to load| | | tion of IHCFCOMH. | 
| | module. | | | | 
--------- +----—------------—---------------- | |3. Returns control to load | 
{I/O List|{1. Receives control from load | | | module. | 
[Section | module, converts input data] }-------- t------- 9 ---- + { 
| | for A using IHCFCVTH, and| {I70 List]1. Receives control from load _ | 
| 1 moves converted data to A. | [Section | module, converts D(1), and| 
| | | | | moves D(1) to output buffer. | 
| {2. Returns control to load| l | | 
| j module. | | }2. Returns control to load| 
i i | | | module. | 
i {3. Receives control from load] | | | 
| | module, converts input data] | {3. Receives control from load| 
| | for B, and moves converted| | | module, converts D(2), and| 
| | data to B. | | | moves D(2) to output buffer. | 
| I | | | | 
| }4. Returns control to load] | }4. Returns control to load| 
| | module. | | | module. | 
| i | I | . | 
| {5. Receives control from load| | [5. Receives control from 1load| 
| | module, converts input data | | module, converts D(3), and| 
| | for C, and moves converted] | | moves D(3) to output buffer. | 
| | data to C. | | | | 
| | | |6. Returns control to load| 
l {6. Returns control to load| | | module. | 
| | module. | --------- +-----------------~—-------------- 
--------- +-------------—-—------+------------ {Closing {1. Receives control from load | 
{Closing |1. Receives control from load | {Section | module and branches to| 
|Section | module and closes out MI/0O| | ] IHCFIOSH to write contents| 
| | operation. | | | of output buffer. | 
| | | | | 
| }2. Returns control to load| | j2. Returns control to load| 
| | module to continue load | | | module to continue load| 
| {| | module execution. | | | module execution. | 
Dest ee ea eats Se a ee J be eee = Be inst ae i ee a ee J 
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READ NOT REQUIRING A FORMAT: The process-— 
ing performed by IHCFCOMH for the following 
READ statement is illustrated in Table 31. 


READ (5) X,Y,2Z 


Table 31. IHCFCOMH Processing for a READ 


Not Requiring a Format 


| Raia? ican: We am Ren a ye ye ee 1 
{Opening [1. Receives control from load | 


|Section | module and branches to| 
| | IHCFIOSH to initialize data] 
| | set for reading. | 
| i 1 
| {2. Returns control to load | 
| | module. | 
l [ | 
p------~-}-------------------------------- 1 
|I“O List|1. Receives control from ioad | 
{Section | module and moves input data] 
{ I to X. { 
| | | 
| j2. Returns control to load| 
| | module. | 
| | | 
| {3. Receives control from load| 
| | module and moves input data| 
| | to Y. | 
| I | 
| }4. Returns control to load] 
| | module. | 
| | | 
| {5. Receives control from load] 
| | module and moves input data| 
| | to Z. | 
| | I 
| {6. Returns control to load| 
| | module. | 
}--~-~---}~---—------—-~~—-—-------------- 
{Closing |1. Receives control from load | 
{Section | module and branches to] 
| | IHCFIOSH to read successive] 
| | records until the end-of-| 
| | logical-record indicator is| 
| | encountered. | 
| | | 
| {2. Returns control to load| 
| | module to continue load | 
| | module execution. | 
 peines etee ergot a a re Sa te es 4 
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WRITE NOT REQUIRING A FORMAT: The process- 
ing performed by IHCFCOMH for the following 
WRITE statement is illustrated in Table 32. 


IHCFIOSH to write contents| 
of output buffer. | 


| 
Returns control to load| 
module to continue load| 
module execution. | 


Nh 
CY) 


WRITE (6) (W(J9),J=1,10) 
Table 32. MIHCFCOMH Processing for a WRITE 
Not Requiring a Format 

foS==-S=s> Te ae ee 1 
[Opening |1. Receives control from load | 
{Section | module and branches to] 
| | IHCFIOSH to initialize data| 
| | for writing. | 
| | | 
{ {2.- Returns control to load| 
| | nodule. | 
}-------- $--------=-~-----~--~------------ 
|I1/70 List]1. Receives control from load _ | 
|Section | module and moves W(1) to| 
| | output buffer. | 
| | | 
| {2. Returns control to load| 
| | module. | 
| | | 
| }3. Receives control from _ ioad| 
| | module and moves W(2) to] 
| | output buffer. | 
| | | 
| j4. Returns control to load| 
| | module. | 
| | | 
| |. | 
| |. i 
| |- | 
{ | { 
| |5. Receives control from load] 
| | module and moves W(10) to| 
| | output buffer. | 
| | | 
| j6. Returns control to load| 
| | module. | 
Sp Spe { 
{Closing |{1. Receives control from load | 
{Section | moduie and branches to| 

| 

| 

| 

| 

| 

| 

L 


| 
| 
{ 
| 
| 
! 
| 
| 
| 
| 
{ 
| 
I 
! 
| 
| 
| 
| 
{ 
| 
| 
I 
I 
| 
i 
| 
| 
| 
| 
I 
! 
1 
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READ/WRITE Statement Using NAMELIST 


Included in the calling sequence to 
IHCNAMEL1? generated by the compiler when it 
detects a READ or WRITE using a NAMELIST is 
a pointer to the object-time namelist dic- 
tionary associated with the READ or WRITE. 
This dictionary contains the names and 
addresses of the variables and arrays into 
which data is to be read or from which data 
is to be written. The dictionary aiso 
contains the information needed to select 
the conversion routine that is to convert 
the data to be placed into the variables or 
arrays, or to be taken from the variables 
and arrays. 


READ USING NAMELIST: The data set contain- 


ing the data to be input to the variables 
or arrays is initialized and successive 
records are read until the one containing 


the namelist name corresponding to that in 
the namelist dictionary is encountered. 
The next record is then read and processed. 


The record is scanned and the first name 
is obtained. The name is compared to the 
variable and array names in the namelist 
dictionary. If the name does not agree, an 
error is Signaled and load module execution 
is terminated. If the name is in the 
dictionary, processing of the matched vari- 
able or array is initiated. 


Each initialization constant assigned to 
the variable or an array element is 
obtained from the input. record. (One con- 
stant is required for a variable. A number 
of constants equal to the number of ele- 
ments in the array is required for an 
array. A constant may be repeated for 
successive array elements if appropriately 
specified in the input record.) The 
appropriate conversion routine is selected 
according to the type of the variable or 
array element. Control is then passed to 
the conversion routine to convert the con- 
stant and to enter it into its associated 
variable or array element. 


The process is repeated for the second 
and subsequent names in the input record. 
When an entire record has been processed, 
the next is read and processed. 


Processing is terminated upon recogni- 
tion of the &END record. Control is then 
returned to the calling routine within the 
load module. 


A4THCNAMEL is included in the load module 
only if reads and writes using NAMELISTs 
appear in the compiled program. Cails are 
made directly to FRDNL# (for READ) or to 
FWRNL# (for WRITE). 
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WRITE USING NAMELIST: The 
Which the variables and arrays are to be 
written is initialized. The namelist name 
is obtained from the namelist dictionary 
associated with the WRITE, moved to an I/0 
buffer, and written. The processing of the 
variables and arrays is then initiated. 


dgata set upon 


The first variable or array name in the 
dictionary is moved to an I/O buffer fol- 
lowed by an equal sign. The appropriate 
conversion routine is selected according to 
the type of the variable or array elements. 
Controi is then passed to the conversion 
routine to convert the contents of the 
variable or the first array element and to 
enter it into the I/O buffer. A comma is 
inserted into the buffer following the 
converted quantity. If an array is being 
processed, the contents of its second and 
subsequent elements are converted, using 
the same conversion routine, and placed 
into the I/O buffer, separated by commas. 
When all of the array elements have been 
processed or if the item processed was a 
variable, the next name in the dictionary 
is obtained. The process is repeated for 
this and subsequent variable or array 
names. 


If, at any time, the record length is 
exhausted, the current record is written 
and processing resumes in the normal fash- 
ion. 


When the last variable or array has been 
processed, the contents of the current 
record are written, the characters &END are 
moved to the buffer and written, and con- 
trol is returned to the calling routine 
within the load module. 


I/O DEVICE MANIPULATION ROUTINES 


The I/O device manipulation routines of 


ITHCFCOMH implement the BACKSPACE, REWIND, 
and END FILE source statements. These 
routines receive control from within the 


load module via calling sequences that are 
generated by the compiler when these state- 
ments are encountered. 


Note: The I/O device manipulation routines 
apply only to sequential access I/O devices 
(e.g., tape units). BACKSPACE, REWIND, and 
ENDFILE requests for direct access data 
sets are ignored. 


The implementation of REWIND and END 
FILE statements is straightforward. The 
I/O device manipulation routines submit the 
appropriate control request to IHCFIOSH, 
the I/O interface module. After the 
request is executed, control is returned to 
the calling routine within the load module. 


The BACKSPACE statement is processed in 
a Similar fashion. However, before control 
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is returned to the calling routine, it is 
determined whether the record backspaced 
over is an element of a data set that does 
not require a format. If the record is an 
element of such a data set, that record is 
read into an I/O buffer and the record 
count is obtained from its control word. 
Backspace control requests, equal in number 
to the record count, are then issyed and 
control is returned to the calling routine. 
If the record is not an element of such a 
data set, control is returned directly to 
the calling routine. 


WRITE-TO-OPERATOR ROUTINES 


The write-to-operator routines of 
IHCFCOMH implement the STOP and PAUSE 
source statements. These routines receive 


control from within the load module via 
calling sequences generated by the compiler 
upon recognition of the STOP and PAUSE 
statements. 


STOP: A write-to-operator (WTO) macro- 
instruction is issued to display the 
message associated with the STOP statement 
on the console. Load module execution is 
then terminated by passing control to the 
program termination routine of IHCFCOMH. 


PAUSE: A write-to-operator-with-reply 
(WTOR) macro-instruction is issued to dis- 
play the message associated with the PAUSE 
statement on the console and to enable the 
operator's reply to be transmitted. A WAIT 
macro-instruction is then issued to deter- 
mine when the operator's reply has been 
transmitted. After the reply has_ been 
received, control is returned to the cail- 
ing routine within the load module. 


UTILITY ROUTINES 


The utility routines of IHCFCOMH perform 
the following functions: 


Process object-time error messages. 
Process arithmetic-type program inter- 
ruptions. 

¢ Terminate load module execution. 


PROCESSING OF ERROR MESSAGES: The error 


message processing routine (IBFERR) 
receives control from various FORTRAN 
library subprograms when they detect 


object-time errors. 


Error message processing consists of 
initializing the data set upon which the 
message is to be written and also of 
writing the message. If the type of error 
requires load module termination, control 
is passed to the termination routine of 
THCFCOMH; if not, control is returned to 
the calling routine. 
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PROCESSING OF ARITHMETIC INTERRUPTIONS: 
The arithmetic-interrupt routine (IBFINT) 
of IHCFCOMH initially receives control from 
within the load module via a compiler- 
generated calling sequence. The call is 
placed at the start of the executable 
coding of the load module so that the 
interrupt routine can set up the program 
interrupt mask. Subsequent entries into 
the interrupt routine are made through 
arithmetic-type interruptions. 


The interrupt routine sets up the 
program interrupt mask by means of a SPIE 
macro-instruction. This instruction speci- 
fies the type of arithmetic interruptions 
that are to cause control to be passed to 
the interrupt routine, and the location 
within the routine to which control is to 
be passed if the specified interruptions 
occur. After the mask has been set, con- 
trol is returned to the calling routine 
within the load module. 


In processing an arithmetic interrup- 
tion, the first step taken by the interrupt 
routine is to determine its type. If 
exponential overflow Or underflow has 
occurred, the appropriate indicators, which 
are referenced by OVERFL (a library 
subprogram), are set. If any type of 
divide check caused the interruption, the 
indicator referenced by DVCHK (also a 
library subprogram) is set. 


Regardless of the type of interruption 
that caused control to be given to the 
interrupt routine, the old program PSW is 
written out for diagnostic purposes. 


After the interruption has been proc- 
essed, control is returned to the inter- 
rupted routine at the point of interrup- 
tion. 


PROGRAM TERMINATION: The load module ter- 
mination routine (IBEXIT) of IHCFCOMH 
receives control from various library sub- 
programs (e.g., DUMP and EXIT) and from 
other IHCFCOMH routines ¢te.g., the routine 
that processes the STOP statement). 


This routine terminates execution of the 
load module by the following means: 


e Calling the appropriate I/O 
interface(s) to check (via the CHECK 
macro-instruction) outstanding write 


requests. 

e Issuing a SPIE macro-instruction with 
no parameters indicating that the FOR- 
TRAN object module no longer desires to 
give special treatment to program 
interruptions and does not want maska- 
ble interruptions to occur. 

e Returning to the operating 
supervisor. 


system 


CONVERSION ROUTINES (IHCFCVTH) 


The conversion routines (refer to Table 
34) either convert data to be placed into 
I/O list items or convert data to be taken 
from I/O list items. 


These routines receive control either 
from the I/0 list section of IHCFCOMH 
during its processing of list items for 
READ/WRITE statements requiring a format, 
from the routines that process READ/WRITE 
statements using a NAMELIST, or from the 
DUMP and PDUMP subprograms. 


Each conversion routine is associated 
with a conversion type format code and/or a 
type. If an I/O list item for READ/WRITE 
statement requiring a format is being proc- 
essed, the conversion routine is selected 
according to the conversion type format 


code which is to be applied to the list 
item. If a list item for a READ/WRITE 
using a NAMELIST is being processed, the 


conversion routine is selected according to 
the type of the list item. 


If a READ statement is being implement- 


ed, the conversion routine obtains data 
from the I/O buffer, converts it according 
to its associated conversion type format 


code or type, and enters the converted data 
into the list item. The process is re- 
versed if a WRITE statement is being imple- 
mented. 


For the DUMP and PDUMP subprograms, the 
format code parameter passed to them deter- 
mines the selection of the output conver- 
sion routine to be used to place the output 
in the desired form. 


LHCFIOSH 


IHCFIOSH, the object-time FORTRAN 
sequential access input/output data manage- 
ment interface, receives I/O requests from 
IHCFCOMH and submits them to the appropri- 
ate BSAM (basic sequential access method) 
routines and/or open and close routines for 
execution. 


Chart 27 illustrates the overall logic 
and the relationship among the routines of 
IHCFIOSH. Table 35, the IHCFIOSH routine 
directory, lists the routines used in 
IHCFIOSH and their functions. 


BLOCKS AND TABLES USED 


IHCFIOSH uses the following blocks and 


table during its processing of sequential 
access input/output requests: (1) unit 
blocks, and (2) unit assignment table. The 


unit blocks are used to indicate I/O activ- 
ity for each unit number (i.e., data set 
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reference number) and to indicate the type 
of operation requested. In addition, the 
unit blocks contain skeletons of the data 
event control biocks (DECB) and the data 
control blocks (DCB) that are required for 
I/O operations. The unit asSignment table 
is used as an index to the unit blocks. 


Unit Blocks 


The first reference to each unit number 
(data set reference nun.ber) by an 
input/output operation within the FORTRAN 
load module causes IHCFIOSH to construct a 
unit block for each unit number. The main 
Storage for the unit blocks is obtained by 
IHCFIOSH via the GETMAIN macro-instruction. 
The addresses of the unit blocks are placed 


in the unit assignment table as the unit 
blocks are constructed. All subsequent 
references to the unit numbers are _ then 


Made through the unit assignment table. 
Figure 60 illustrates the format of a unit 
block for a unit that is defined asa 
sequential access data set. 


aaa | ere 5 aaa A ee | 

| ABYTE| BBYTE|CBYTE | LIVECNT | 

cen aer Fen! oc eSess | 
|Address of Buffer 1 | 
----------—---------------- 4 | Housekeeping 
|Address of Buffer 2 | (Section 
}------------------------- { 
{Current buffer pointer | 
|~------------------------ { 

[Record offset | 

a A tae se Se La en | 

|DECB skeleton section | 

as Ee ere ae eee a eee eee 4 


Format of a Unit Block for a 
Sequential Access Data Set 


Figure 60. 


Each unit block is divided into three 
sections: a housekeeping section, a DECB 


skeleton section, anda DCB skeleton sec- 
tion. 

HOUSEKEEPING SECTION: The housekeeping 
section is maintained by IHCFIOSH. The 
information contained in it is used to 


indicate data set type, to keep track of 
I/O buffer locations, and to keep track of 
addresses internal to the I/O buffers to 
enable the processing of biocked records. 
The fields of this section are: 


e ABYTE. This field, containing the data 
set type passed to IHCFIOSH by 
IHCFCOMH, can be set to one of the 
following: 


FO - Input data set requiring a format. 
FF - Output data set requiring a for- 
mat. 
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00 - Input data set not requiring a 
format. 

OF - Output data set not requiring a 
format. 

e BBYTE. This field contains bits that 


are set and examined by IHCFIOSH during 
its processing. The bits and their 
meanings are as follows: 


Bit on 
0 - exit to IHCFCOMH on I/O error 
1 - I/O error occurred 
2 - current buffer indicator 
3 - not used 
4 - end-of-current buffer indicator 
5 - plocked data set indicator 
6 - variable record format switch 
7 - not used 
e CBYTE. This field also contains bits 
that are set and examined by IHCFIOSH. 
The bits and their meanings are as 
foliows: 
Bit on 
0 - data control block opened 
1 - data control block not TCLOSEd 
2 - data control block not previously 
opened 
3 - buffer pool attached 
4 —- data set not previously rewound 
5 ~ data set not previously backspaced 
6 - concatenation occurring -- reissue 
READ 
7 - not used 
e LIVECNT. This field indicates whether 


any I/O operation performed for this 
data set is unchecked. (A value of 1 
indicates that a previous read or write 
has not been checked; a value of 0 
indicates that all previous read and 
write operations for this data set have 
been checked.) 


e Address of Buffer 1 and Address of 
Buffer 2. These fields contain point- 
ers to the two I/0 buffers obtained 
during the opening of the data control 
block for this data set. 


e Current Buffer Pointer. This field 
contains a pointer to the I/O buffer 
currently being used. 


® Record Offset. This field contains a 
pointer to the current logical record 
within the current buffer. 


SKELETON SECTION: The DECB (data 
event control block) skeleton section is a 
block of main storage within the unit 
block. It is of the same form as the DECB 


DECB 
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constructed by the control program for an L 
form of an S-type READ or WRITE macro- 
instruction (refer to the publication IBM 


Systen/ 360 Operating System: Control 
Program Services). The various fields of 


the DECB skeleton are filled in by IHCFI- 
OSH; the completed block is referred to 
when IHCFIOSH issues a read/write request 


The read/write field is filled in 
at open time. For each I/O operation, 
THCFIOSH supplies IHCFCOMH with: (1) an 
indication of the type of operation (read 
or write), and (2) the length of and a 
pointer to the I/O buffer to be used for 
the operation. 


to BSAM. 


DCB SKELETON SECTION: The DCB (data _ con- 
trol biock) skeleton section is a block of 
main storage within the unit block. It is 
of the same form as the DCB constructed by 
the control program for a DCB macro- 
instruction under BSAM (refer to the 


publication IBM System/360 Operating Sys- 


tem: Control Program Services). The var- 
ious fields of the DCB skeleton are filled 


in by the control program when the DCB for 


the data set is opened (refer to the 
publication IBM System/360 Operating Sys- 


tem: Concepts and Facilities). (Standard 
default values may also be inserted in the 


DCB skeleton by IHCFIOSH. Refer to "Unit 
Assignment Table" for a discussion of when 


default values are inserted into the DCB 
skeleton.) 
Unit Assignment Table 

The unit assignment table (IHCUATBL) 
resides on the FORTRAN system library 
(SYS1.FORTLIB). Its size depends on the 
Maximum number of units that can be 


referred to during execution of any FORTRAN 
load module. This number (< 99) is speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro- 
instruction. 


The unit assignment table is designed to 
be used by both IHCFIOSH and IHCDIOSH. It 
is included once, by the linkage editor, in 
the FORTRAN load module as a result of an 
external reference to it within IHCFIOSH 
and/or IHCDIOSH. 


The unit assignment table contains a 16 
byte entry for each of the unit numbers 
that can be referred to by the user. These 
entries differ in format depending on 
whether the unit has been defined as a 
sequential access or a direct access data 
set. ; 


Figure 61 illustrates the format of the 
unit assignment table. 


lunit number (DSRN) 
{being used for current 


| 

| 
suaastants | tn x 16 4 bytes| 
}--------7---~--- y~----+-7--------4------- 
| ERRMSG H READ | PRINT | PUNCH 
} DSRN2 | DSRN3 | DSRN* | DSRNS {4 bytes| 
ea i A it a oa 


DS EY SS SS I NS SS A te RS ee a ee ee a 


me cee ee cnt ee me ce ee ce ee cee ce ce ce es ee ee es es ee oe 


re ire ee a a a ee ee cee ee me ee re ce ee ee a a ce ee ee ee ee he ee ee ee ee oe 


is the maximum number of units that| 
can be referred to by the FORTRAN  1load| 


module. The size of the unit table is| 
equal to (8 + n x 16) bytes. | 
2Unit number (DSRN) of error output| 
device. | 


3Unit number (DSRN) of input device for a] 
read of the form: READ b,ilist. | 
*Unit number (DSRN) of output device for| 
a print operation of the form: PRINT| 
b, list. | 
SUnit number (DSRN) of output device for] 
a punch operation of the form: PUNCH| 
b,iist. | 
6The UBLOCKn field contains either af| 
pointer to the unit block constructed] 
for unit number n if the unit is being| 
used at object-time, or a value of 1 if] 
the unit is not being used. | 
7The defauit values for the various unit] 
numbers are specified by the user and| 
are assembled into the unit assignment] 
table entries during the system genera-| 
tion process. The default values are| 








used only by IHCFIOSH; they are ignored| 
by IHCDIOSH. | 
8If the unit is defined as a direct] 
access data set, the LISTn field con-| 


tains a pointer to the parameter 1list| 
that defines the direct access data set. | 


Otherwise, this field contains a value] 

p OF 1. | 
Jane ae eee sve es ane nn ne a eo ean cm ae ac Seen ee ee aD ap egy SD aD eo aD =e ne a en anes eS oo dj 
ries 61. Unit Assignment Table Format 


Because IHCFIOSH deals only with sequen- 
tial access data sets, the remainder of the 
discussion on the unit assignment table is 
devoted to unit assignment table entries 
for sequential access data sets. If IHCFI- 
OSH encounters a reference to a direct 
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access data set, it is considered as an 
error, and control is passed to the load 
module termination routine of IHCFCOMH. 


The pointers to the unit blocks created 
for sequential data sets are inserted into 
the unit assignment table entries by IHCFI- 
OSH when the unit blocks are constructed. 


Note: Default values are standard values 
that IHCFIOSH inserts into the appropriate 





fields (e.g., BUFNO) of the DCB skeleton 
section of the unit blocks if the user 
either: 


e Causes the load module to be executed 
via a cataloged procedure, or 


e Fails, in stating his own procedure for 
execution, to include in the DCB param- 
eter of his DD statements those _ sub- 
parameters (e.g., BUFNO) he is permit- 
ted to include (refer to the publica- 
tion 


IBM System/360 Operating System: 
FORTRAN IV {H) Programmer's Guide). 


Control is returned to IHCFIOSH during 


data control block opening so that it can 
determine if the user has included the 
Ssubparameters in the DCB parameter of his 
DD statements. IHCFIOSH examines the DCB 
Skeleton fields corresponding to user- 
permitted subparameters, and upon 
encountering a null field (indicating that 
the user has not specified the 


Subparameter), inserts the standard value 
(i.e., the default value) for the subparam- 
eter into the DCB skeleton. (If the user 
has included these subparameters in his DD 
statement, the control program routine per- 
forming data control block opening inserts 
the subparameter values, before giving con- 
trol to IHCFIOSH, into the DCB skeleton 
fields reserved for those values.) 


BUFFERING 


All input/output operations are double 
buffered. (The double buffering scheme can 
be overridden by the user if he specifies 
in a DD statement: BUFNO=1.) This . implies 
that during data control block opening, two 
buffers will be obtained. The addresses of 
these buffers are given alternately to 
IHCFCOMH as pointers to: 


e Buffers to be filled (in the case of 
output). 

e Information that has been read in and 
is to be processed (in the case of 
input). 


COMMUNICATION WITH THE CONTROL PROGRAM 


In requesting services of the control 
program, IHCFIOSH uses L and E forms of 
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S-type macro-instructions (refer to the 


publication IBM System/360 Operating Sys- 
tem: Control Program Services). 


OPERATION 


The 
into five sections: 


processing of IHCFIOSH is divided 
initialization, read, 
write, device manipulation, and closing. 
When called by IHCFCOMH, a_ section of 
IHCFIOSH performs its function and then 
returns control to IHCFCOMH. 


Initialization 


The initialization action taken by 
IHCFIOSH depends upon the nature of the 
previous I/0 operation requested for the 
data set. The previous operation possibil- 
ities are: 


No previous operation. 

Previous operation read or write. 
Previous operation backspace. 

Previous operation write end-of-data 
set. 

e Previous operation rewind. 


NO PREVIOUS OPERATION: If no previous 
operation has been performed on the unit 
specified in the I/O request, the initiali- 
zation section generates a unit block for 
the unit number. The data set to be 
created is then opened (if the current 
operation is not rewind or backspace) via 
the OPEN macro-instruction. The addresses 
of the I/0 buffers, which are obtained 
during the opening process and placed into 
the DCB skeleton, are placed into the 
appropriate fields of the housekeeping sec- 
tion of the unit block. The DECB skeleton 
is then set to reflect the nature of the 
operation (read or write), the format of 
the records to be read or written, and the 
address of the I/O buffer to be used in the 
operation. 


If the requested operation is a write, a 
pointer to the buffer position, at which 
IHCFCOMH is to place the record to be 
written, and the block size or logical 
record length (to accommodate blocked logi- 
cal records) are placed into registers, and 
control is returned to IHCFCOMH. 


If the requested operation is a read, a 
record is’ read, via a READ macro- 
instruction, into the I/0 buffer, and the 
operation is checked for completion via the 
CHECK macro-instruction. A pointer to the 
location of the record within the buffer, 
along with the number of bytes read or the 
logical record length, are placed into 
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registers, and control is returned to 


ITHCFCOMH. 


Note: During the opening process, control 
is returned to the IHCDCBXE routine in 
IHCFIOSH. This routine determines if the 
data set being opened is a 1403 printer. 
If it is, the RECFM field in the DCB for 
the data set is altered to machine carriage 
control (FM). In addition, a pointer to 
the unit block generated for the printer, 
and the physical address of the printer are 
placed into a control block area (CTLBLK) 
for the printer within IHCFIOSH. CTLBLK 
also contains a third print buffer. This 
buffer is used in conjunction with the two 
buffers already obtained for the printer. 


Figure 62 illustrates the format of 

CTLBLK. 
oo ee ee i Youmaran rics 

CTLBLK|a(BUF 3) {| 4 bytes| 
}------------------------- }--------- 
jJa(unit block) | 4 bytes| 
~--------~- 1------------- t--------- { 
ja(printer) |record length{ 4 bytes] 
}~-------~-- Lew — nana +----—---- 1 
{+ FTOO | 4 bytes| 
~---------~-------------- }~--------4 
{2 FOOL | 4 bytes| 
a a eae oe ea ne i eae 

BUF3 [third print buffer {144 bytes| 
}—-----------~--.~-----__-  Toaeeacee a a eee 
|+Used in the task input/output] 
| table (TIOT) search. | 
betes ee eee ee ee 4 

Figure 62. CTLBLK Format 

PREVIOUS OPERATION READ OR WRITE: If the 


previous operation performed on the unit 
Specified in the present I/0 request was 
either a read or write, the initialization 
section determines the nature of the pres- 
ent I/O request. If it is a write, a 
pointer to the buffer position, at which 
IHCFCOMH is to place the record to be 
written, and the block size or logical 
record length are placed into registers, 
and control is returned to IHCFCOMH. 


If the operation to be performed is a 
read, a pointer to the buffer location of 
the record to be processed, along with the 
number of bytes read or logical record 
length, are placed into registers, and 
control is returned to IHCFCOMH. 


PREVIOUS OPERATION BACKSPACE: If the pre- 
vious operation performed on the unit spec- 
ified in the present I/O request was a 
backspace, the initialization section de- 
termines the type of the present operation 
(read or write) and modifies the DECB 
skeleton, if necessary, to reflect the 
Operation type. (If the operation type is 
the same as that of the operation that 
preceded the backspace request, the DECB 


skeleton need not be modified.) Subsequent 
processing steps are the same as those 
described for "No Previous Operation," 


starting at the point after the DECB skele- 
ton is set to reflect operation type. 


PREVIOUS OPERATION WRITE END-OF-DATA SET: 
If the previous operation performed on the 
unit specified in the present I/O request 
was a write end-of-data set, a new data set 
using the same unit number is to be creat- 
ed. In this case, the initialization sec- 
tion closes the data set. Then, in order 
to establish a correspondence between the 
new data set and the DD statement describ- 
ing that data set, IHCFIOSH increments the 
unit sequence number of the ddname. (The 
ddname is placed into the appropriate field 
of the DCB skeleton prior to the opening of 
the initial data set associated with the 
unit number.) During the opening of the 
data set, the ddname will be used to merge 
with the appropriate DD statement. The 
data set is then opened. Subsequent proc- 
essing steps are the same as those de- 
scribed for "No Previous Operation," start- 
ing at the point after the data set is 
opened. 


PREVIOUS OPERATION REWIND: If the previous 
operation performed on the unit specified 
in the present I/O request was a rewind, 
the ddname is initialized (set to FTxxF001) 
in order to establish a correspondence 
between the initial data set associated 
with the unit number and the DD statement 
describing that data set. The data set is 
then opened. Subsequent processing steps 
are the same as_ those described for "No 
Previous Operation," starting at the point 
after the data set is opened. 


Read 


The read section of IHCFIOSH performs 
two functions: (1) reads physical records 
into the buffers obtained during data set 
opening, and (2) makes the contents of 
these buffers available to IHCFCOMH for 
processing. 


If the records being processed are 
blocked, the read section does not read a 
physical record each time it is given 
control. IHCFIOSH only reads a physical 
record when all of the logical records of 
the blocked record under consideration have 
been processed by IHCFCOMH. However, if 
the records being processed are either 
unblocked or of U-format, the read section 
of IHCFIOSH issues a READ macro-instruction 
each time it receives control. 


The reading of records by this section 
is overlapped. That is, while the contents 
of one buffer are being processed, a physi- 
cal record is being read into the other 
buffer. When the contents of one buffer 
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have been processed, the read into the 
other buffer is checked for completion. 
Upon completion of the read operation, 
processing of that buffer‘s contents is 


initiated. In addition, a read into the 
second buffer is initiated. 

Each time the read section is given 
control it makes the next record available 


to IHCFCOMH for processing. (In the case 
of blocked records, the record presented to 
IHCFCOMH is logical.) The read section of 
IHCFIOSH places: (1) a pointer to the 
record's location in the current I/O buf- 
fer, and (2) the number of bytes read or 
logical record length into registers, and 
then returns control to IHCFCOMH. 


Write 
The write section of IHCFIOSH performs 


two functions: (1) writes physical records, 
and (2) provides IHCFCOMH with buffer space 


in which to place the records to be writ- 
ten. 
If the records being written are 


blocked, the write section does not write a 
physical record each time it is given 
control. IHCFIOSH oniy writes a physical 
record when all of the logical records that 
comprise the blocked record under consider- 
ation have been placed into the I/O buffer 
by THCFCOMH. However, if the records being 


written are either unblocked or of U- 
format, the write section of IHCFIOSH 
issues a WRITE macro-instruction each time 


it receives control. 


The writing of records by this section 
is overlapped. That is, while IHCFCOMH is 


filling one buffer, the contents of the 
other buffer are being written. When an 
entire buffer has been filled, the write 


other buffer is checked for com- 
pletion. Upon completion of the write 
operation, IHCFCOMH starts placing records 
into that buffer. In addition, a write 
from the second buffer is initiated. 


from the 


Each time the write section is given 
control, it provides IHCFCOMH with buffer 
space in which to place the record to be 
written. IHCFIOSH places: (1) a pointer to 
the location within the current buffer at 
which IHCFCOMH is to place the record, and 
(2) the block size or logical record length 
into registers, and then returns control to 
IHCFCOMH. 





Note: The write section checks to see if 
the data set being written on is a 1403 
printer. If it is, the carriage control 


character is changed to machine code, and 
three buffers, instead of the normal two, 
are used when writing on the printer. 
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ERROR PROCESSING: If an end-of-data set or 
an I/O error is encountered during reading 
or writing, the control program returns 
control to the location within IHCFIOSH 
that was specified during data set initial- 
ization. In the case of an I/O error, 
IHCFIOSH sets a switch to indicate that the 
error has occurred. Control is then 
returned to the control program. The con- 
trol program completes its processing and 
returns control to IHCFIOSH, which interro- 
gates the switch, finds it to be set, and 
passes control to the I/O error routine of 
THCFCOMH. 


In the case of an end-of-data 
IHCFIOSH simply passes control to the 
of-data set routine of IHCFCOMH. 


set, 
end- 


28 illustrates the execution-time 
errors 


Chart 
I/O recovery procedure for any I/0 
detected by the I/O supervisor. 


Device Manipulation 


The device manipulation section of 
IHCFIOSH processes backspace, rewind, and 
write end-of-data set requests. 


BACKSPACE: 
Space request by 


IHCFIOSH processes’ the 
issuing a BSP (physical 
backspace) macro-instruction. It then 
places the data set type, which indicates 
the format requirement, into a register and 
returns control to IHCFCOMH. (IHCFCOMH 
needs the data set type to determine its 
subsequent processing.) 


REWIND: IHCFIOSH processes the rewind 
request by issuing a CLOSE macro- 
instruction, using the REREAD option. This 
option has the same effect as a rewind. 
Control is then returned to ITHCFCOMH. 


WRITE END-OF-DATA SET: 
this request by issuing a CLOSE macro- 
instruction, type = T. It then frees the 
I/O buffers by issuing a FREEPOOL macro- 
instruction, and returns control to 
IHCFCOMH. 


ITHCFIOSH processes 


Closing 


The closing section of IHCFIOSH examines 
the entries in the unit assignment table to 
determine which data control biocks are 
open. In addition, this section ensures 
that all write operations for a data _ set 
are completed before the data control block 
for that data set is closed. This is done 
by issuing a CHECK macro-instruction for 
all doubie-buffered output data sets. Con- 
trol is then returned to IHCFCOMH. 


Note: If a 1403 printer is being used, a 
write from the last print buffer is issued 
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back- . 


to insure that the last line of 
written. 


output is 


IHCDIOSH 


IHCDIOSH, the object-time FORTRAN direct 
access input/output data management inter- 
face, receives I/O requests from IHCFCOMH 
and submits them to the appropriate BDAM 
(basic direct access method) routines 
and/or open and close routines for execu- 
tion. (For the first I/O request involving 
a nonexistent data set, the appropriate 
BSAM routines must be executed prior to 
linking to the BDAM routines. The BSAM 
routines format and create a new data set 
consisting of blank records.) 


IHCDIOSH receives control from: (1) the 
initialization section of the FORTRAN load 
module if a DEFINE FILE statement is 
included in the source module, and (2) 
IHCFCOMH whenever a READ, WRITE, or FIND 
direct access statement is encountered in 
the load module. 


Charts 29 and 30 illustrate the overall 
logic and the relationship among the rou- 
tines of IHCDIOSH. Table 36, the IHCDIOSH 
routine directory, lists the routines used 
in IHCDIOSH and their functions. 


BLOCKS AND TABLE USED 


IHCDIOSH uses the following blocks and 
table during its processing of direct 
access input/output requests: (1) unit 
blocks, and (2) unit assignment table. The 
unit blocks are used to indicate I/O activ- 
ity for each unit number (i.e., data set 
reference number) and to indicate the type 
of operation requested. In addition, each 
unit block contains skeletons of the data 
event control blocks (DECB) and the data 
control block (DCB) that are required for 
I/O operations. The unit assignment table 
is used as an index to the unit blocks. 


Unit Blocks 


The first reference to each unit number 
(i.e., data set reference number) by a 
direct access input/output operation within 
the FORTRAN load module causes IHCDIOSH to 
construct a unit block for each of the 
referenced unit numbers. The main storage 
for the unit blocks is obtained by IHCDIOSH 
via the GETMAIN macro-instruction. The 
addresses of the unit blocks are inserted 
into the corresponding unit assignment 
table entries as the unit blocks are con- 
structed. Subsequent references to the 
unit numbers are then made through the unit 
assignment table. 


Figure 63 illustrates the format of a 
unit block for a unit that has been defined 
as a direct access data set. 


Aan ipka Ia Te ey 
jIOTYPE |STATUSU| not | not | 4 bytes | 
| | } used | used | | 
-------- Bites Sanne f comers 4 == 4 
| RECNUM | 4 bytes | 
Sea ES eae 
| STATUSA| CURBUF } 4 bytes | 
pao 2b ne }-------—-- { 
| BLKREFA | 4 bytes | 
(=== 7 ne ees Posse ss 1 
| STATUSB | NXTBUF | 4 bytes j 
}------- 4——----~~--~~--------- }----------- { 
| BLKREFB | 4 bytes | 
pram ann nnn nnn nn nnn fama { 
| DECBA {| 28 bytes | 
}--=--~----------------------- }---~------- { 
| DECBB | 28 bytes | 
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| DCB {| 104 bytes | 
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Figure 63. Format of a Unit Block for a 


Direct Access Data Set 


The meanings of the various unit block 
fields are outlined below. 


IOTYPE: This field, containing the data 
set type passed to IHCDIOSH by IHCFCOMH, 
can be set to one of the following: 

FO - input data set requiring a format 


FF - output data set requiring a format 


00 - input data set not requiring a 
format 
OF - output data set not requiring a 
format 
STATUSU: This field specifies the status 
of the associated unit number. The bits 
and their meanings are as follows: 
Bit on 
0 - not used 
1 - error occurred 
2 - two buffers are being used 
3 - data control block for data set is 


open 


4-5 10- U form specified in DEFINE 
FILE statement 
01 - E form specified in DEFINE 
FILE statement 
11 - L form specified in DEFINE 


FILE statement 
6-7 not used 


Note: 
and 3. 


IHCDIOSH references only bits 1, 2, 


Appendix E: 


RECNUM: This field contains the number of 
records in the data set as specified in the 
parameter list for the data set in a DEFINE 
FILE statement. It is filled in by the 


file initialization section after the data 
control block for the data set is opened. 
STATUSA: This field specifies the status 
of the buffer currently being used. The 
bits and their meanings are as follows: 
Bit on 
0 - READ mMacro-instruction has been 
issued 
1 - WRITE macro-instruction has been 
issued 
2 - CHECK macro-instruction has been 
issued 


3-7 Not used 


CURBUF: This field contains the address of 
the DECB skeleton currently being used. It 
is initialized to contain the address of 
the DECBA skeleton by the file initializa- 
tion section of IHCDIOSH after the data 
control block for the data set is opened. 


BLKREFA: This field contains an integer 
that indicates either the relative position 
within the data set of the record to be 


read, or the relative position within the 
data set at which the record is to be 
written. It is filled in by either the 


read or write section of IHCDIOSH prior to 
any reading or writing. In addition, the 
address of this field is inserted into the 
DECBA skeleton by the file initialization 
section of IHCDIOSH after the data control 
block for the data set is opened. 


STATUSB: This field specifies the status 
of the next buffer to be used if two 
buffers are cbtained for this data set 


during data control block opening. The 
bits and their meanings are the same as 
described for the STATUSA field. However, 
if only one buffer is obtained during data 
control block opening, this field is not 
used. 


NXTBUF: This field contains the address of 
the DECB skeleton to be used next if two 
buffers are obtained during data control 
block opening. It is initialized to con- 
tain the address of the DECBB skeleton by 
the file initialization section of IHCDIOSH 
after the data control block for the data 
set is opened. However, if only one buffer 
is obtained during data control block open- 
ing, this field is not used. 


BLKREFB: The contents of this field are 
the same as described for the BLKREFA 
field. It is filled in either by the read 


or the write section of IHCDIOSH prior to 
any reading or writing. In addition, the 
address of this field is inserted into the 
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DECBB skeleton by the file initialization 
section of IHCDIOSH after the data control 
block for the data set is opened. However, 
if only one buffer is obtained during data 
control block opening, this field is not 
used. 


DECBA SKELETON: This field contains’ the 
DECB (data event control block) skeleton to 
be used when reading into or writing from 
the current buffer. It is of the same form 
as the DECB constructed by the _ control 
program for an L form of an S-type READ or 
WRITE macro-instruction under BDAM (refer 


to the publication IBM System/360 Operating 
System: Control Program Services). 


The various fields of the DECBA skeleton 
are filled in by the file initialization 
section of IHCDIOSH after the data control 
block for the data set is opened. The 
completed DECB is referred to when IHCDIOSH 
issues a read or a write request to BDAM. 
For each I/0 operation, IHCDIOSH supplies 
IHCFCOMH with the address of and the size 
of the buffer to be used for the operation. 


DECBB SKELETON: The DECBB skeleton is used 
when reading into or writing from the next 
buffer. Its contents are the same as 
described for the DECBA skeleton. The 
DECBB skeleton is completed in the same 
IManner as described for the DECBA skeleton. 
However, if only one buffer is obtained 
during data control block opening, this 
field is not used. : 


DCB SKELETON: This field contains the DCB 
(data control block) skeleton for the asso- 
ciated data set. It is of the same form as 
the DCB constructed by the control program 
for a DCB macro-instruction under BDAM 
(refer to the publication IBM System/360 


Operating System: Control Program 
Services). 


The various fields of the DCB skeleton 
are filled in by the control program when 
the DCB for the data set is opened (refer 
to the publication IBM System/360 Operating 
System: Concepts and Facilities). 


Unit Assignment Table 


The unit assignment table (IHCUATBL) 
resides on the FORTRAN’ system library 
(SYS1.FORTLIB). Its size depends on the 
maximum number of units that can be 


referred to during execution of any FORTRAN 
load module. This number (<99) is  speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro- 
instruction. 


The unit assignment table is designed to 
be used by both IHCFIOSH and IHCDIOSH. it 
is included once, by the linkage editor, in 
the FORTRAN load module as a resuit of an 
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external reference to it within IHCFIOSH 
and/or IHCDIOSH. 


The unit assignment table contains a 
16-byte entry for each of the unit numbers 
that can be referred to by either IHCDIOSH 
or IHCFIOSH. These entries differ in 
format depending on whether the unit has 
been defined as a direct access or as a 
sequential access data set. Because IHCDI- 
OSH deals only with direct access data 
sets, only the entry for a direct access 
unit is Shown here. (Refer to the IHCFIOSH 
section "Table and Blocks Used", for the 
format of the unit assignment table as a 
whole.) If IHCDIOSH encounters a reference 
to a sequential access data set, it is 
considered aS an error, and control is 
passed to the load module termination rou- 
tine of IHCFCOMH. 


Figure 64 illustrates the unit assign- 
ment table entry format for a direct access 
data set. 


Go ee ee T---—--= 4 
{ Pointer to unit block xx |4 bytes| 
| (UBLOCK xx) | | 
 Fasigd cath acca sense TS AESreues aL SEE ESS RSIS REORDER : opis oie nated { 
| Default values for DSRNxx (only [8 bpytes| 
{| applies to sequential access | | 
{| data sets -- not used by | | 
{| IHCDIOSH) | | 
}----------------~----------------- $------- { 
| Pointer to parameter listxx |4 bytes| 
| (LISTxx) | | 
}--------------------------------- 41------- { 
| UBLOCKxx is the unit block generated | 
| for unit number xx. | 
| | 
| DSRNxx is the unit number for the | 
| direct access data set (xx<99). | 
| | 
| LISTxx is the parameter list that | 
| defines the direct access data _ set | 
| associated with unit number xx. | 
M2 se he en a eo rg ee ee 5 


Figure 64. Unit Assignment Table Entry for 


a Direct Access Data Set 


The pointers to the unit blocks are 
inserted into the unit assignment table 
entries by IHCDIOSH when the unit blocks 
are constructed. 


The pointers to the parameter lists are 
inserted into the unit assignment table 
entries by IHCDIOSH when IHCDIOSH receives 
control from the initialization section of 
the FORTRAN load module being executed. 


BUFFERING 


All direct access 
tions are double-buffered. 
buffering scheme 


input/output opera- 
(The double 
may be overridden by the 


user if he specifies in his DD statements: 
BUFNO=1.) This implies that during data 
control block opening, two buffers will be 
obtained for each data set. The addresses 
of these buffers are given alternately to 
IHCFCOMH as pointers to: 

to be in the case of 


e Buffers filled 


output. 


e Data that has been read in and is to be 
processed in the case of input. 


Each buffer has its own DECB. This 
increases I/O efficiency by overlapping of 
I/O operations. 


COMMUNICATION WITH THE CONTROL PROGRAM 

In requesting services of the control 
program BSAM and BDAM routines, IHCDIOSH 
uses L and E forms of S-type macro- 
instructions (refer to the publication IBM 


Systenv 360 Operating System: Control 
Program Services). 


OPERATION 


The processing of IHCDIOSH is divided 
into five sections: file definition, file 
initialization, read, write, and termina- 
tion. When a section receives control, it 
performs its functions and then returns 
control to the caller (either the FORTRAN 
load module or IHCFCOMH). 


File Definition Section 


The file definition section is entered 
from the FORTRAN load module, via a 
compiler-generated calling sequence, if a 
DEFINE FILE statement is included in the 
FORTRAN source module. The file definition 
section performs the following functions: 

e Checks for the redefinition of each 
direct access unit number. 


the address of each direct 
access unit number's parameter list 
into the appropriate unit assignment 
table entry. 


e Enters 


e Establishes addressability for IHCDIOSH 
within IHCFCOMH. 


Each direct access unit number appearing 
in a DEFINE FILE statement is checked to 
see if it has been defined previously. If 
it has been defined previously, the current 
Gefinition is ignored. If it has not been 
defined previously, the address of its 
parameter list (i.e., the definition of the 
unit number) is inserted into the proper 
entry in the unit assignment table. The 
next unit number if any is then obtained. 
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When the last 
processed in the 
definition 


unit number has been 
above manner, the file 
section stores the address of 
IHCDIOSH into the FDIOCS field within 
IHCFCOMH. This enables IHCFCOMH to link to 
IHCDIOSH when IHCFCOMH encounters a direct 
access I/O statement. Control is then 
returned to the FORTRAN load module to 
continue normal processing. 


File Initialization Section 


The file initialization section receives 
control from IHCFCOMH whenever input or 
output is requested for a direct access 
data set. The processing perfcrmed by the 
initialization section depends on whether 
an I/O operation was previously requested 
for the data set. 


NO PREVIOUS OPERATION: If no operation was 
previously requested for the data set spec- 
ified in the current I/O request, the file 
initialization section first constructs a 
unit block for the data set. (The GETMAIN 
macro-instruction is used to obtain the 
main storage for the unit block.) The 
address of the unit block is inserted into 
the appropriate entry in the unit assign- 
ment table. 


The file initialization section then 
reads the JFCB (job file control block) via 
the RDJFCB macro-instruction. The value in 
the BUFNO field of the JFCB is’ inserted 
into the DCB’ skeleton in the unit block. 
This value indicates the number of buffers 
that are obtained for this data set when 
its data control block is opened. If the 
BUFNO field is null (i.e., if the user dia 
not include the BUFNO subparameter in the 
DD statement for this data set), or other 
than 1 or 2, the file initialization sec- 
tion inserts a value of two into the DCB 
skeleton. 


The file initialization section next 
examines the JFCBIND2 field in the JFCB to 
determine if the data set specified in the 
current I/O request exists. If the 
JFCBIND2 field indicates that the specified 
data set does not exist, and if the current 
request is a write, a new data set is 
created. (If the current request is a 
read, an error is indicated and control is 
returned to IHCFCOMH to terminate load 
module execution. If the current request 
is a find, the request is ignored, and 
control is returned to IHCFCOMH.) If the 
JFCBIND2 field indicates that the specified 
data set already exists, a new data set is 


not created. The file initialization sec- 
tion processing for a data set to be 
created, and for a data set that already 


exists is discussed in the following para- 
graphs. 
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Data _ Set to be Created: The data control 
block for the new data set is first opened 
for the BSAM, load mode, WRITE macro- 
instruction. The BSAM WRITE macro- 


instruction is used to create a new data 
set according to the format specified in 
the parameter list for the data set in a 


DEFINE FILE statement. The data control 
block is then closed. Subsequent file 
initialization section processing after 


creating the new data set is the same as 


that described for a data set that already 
exists (refer to the section “Data Set 
Already Exists"). 

Data_Set Already Exists: The data control 


block for the data set is opened for direct 
accesS processing by the BDAM routines. 
After the data control block is opened, the 
file initialization section fills in var- 
ious fields in the unit block: 


e The number of records in the data set 
is inserted into the RECNUM field. 


°® The address of the DECB' skeletons 
(DECBA and DECBB) are inserted into the 


CURBUF and the NXTBUF fields, respec- 
tively. 

e The addresses of the I/O buffers 
obtained during data control biock 


opening are inserted into the appropri- 
ate DECB skeletons. 


e The address of the BLKREFA and the 
BLKREFB fields in the unit block are 
inserted into the appropriate DECB 
skeletons. 


Note: If the user specifies BUFNO=1 in the 
DD statement for this data set, only one 
I/O buffer is obtained during data control 
block opening. In this case, the NXTBUF 
field, the BLKREFB field, and the DECBB 
skeleton are not used. 





initialization section 
case of no previous 
operation depends upon the nature of the 
I/O request (find, read, or write). This 
processing is the same as that described 
for the case of a previous operation (refer 
to the section “Previous Operation"). 


Subsequent file 
processing for the 


PREVIOUS OPERATION: If an operation was 
previously requested for the data set spec- 
ified in the current I/O request, the file 
initialization section processing depends 
upon the nature of the current I/O request. 


If the current request is either a find 


or a read, control is passed to the read 
section. 
If the current request is a write, 


control is passed to the secondary entry in 
the write section. 
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Read Section 


The read section of IHCDIOSH processes 
read and find requests. The read section 


may be entered either from the file ini- 
tialization section of IHCDIOSH, or from 
IHCFCOMH. In either case, the processing 


performed is the same. In processing read 
and find requests, the read section per- 
forms the following functions: 


e Reads physical records into the 
buffer(s) obtained during data control 
block opening. 

e Makes the contents of these buffers 
available to IHCFCOMH for processing. 

e Updates the associated variable that is 
defined in the DEFINE FILE statement 
for the data set. 


The read section, upon receiving con- 
trol, first checks to see if the record to 
be found or read is already in an I/0 


buffer. Subsequent read section processing 
depends upon whether the record is in the 
buffer. 


RECORD IN BUFFER: If a record is in the 
buffer, the read section determines whether 
the current request is a find or a read. 


If the current request is a find, the 
associated variable for the data set is 
updated so that it points to the relative 
position within the direct access data set 
of the record that is in the buffer. 
Control is then returned to IHCFCOMH. 


If the current request is a read, the 
read operation that read the record into 
the buffer is checked for completion. The 
read section then places the address of the 
buffer and the size of the buffer into 
registers for use by IHCFCOMH. The asso- 
ciated variable for the data set is updated 
so that it points to the relative position 
within the direct access data set of the 
record following the record just read. 
Control is then returned to IHCFCOMH. 


RECORD NOT IN BUFFER: If a record is not 
in the buffer, the read section first 
obtains the address of the buffer to be 
used for the current request. The relative 
record number of the record to be read is 
then inserted into the appropriate BLKREF 
field in the unit block (i.e., BLKREFA or 
BLKREFB). The proper record is then read 
from the specified data set into the buf- 
fer. Subsequent read section processing 
for the case of a record not in the buffer 
is the same as that described for a record 
in the buffer (refer to the section "Record 
In Buffer"). 


Note 1: Record retrieval can proceed con- 
currently with CPU processing only if the 


user alternates FIND statements with READ 
statements in his program. 

Note 2: If an I/O error occurs during 
reading, the control program returns con- 
trol to the synchronous exit routine 
(SYNADR) within IHCDIOSH. The SYNADR  rou- 
tine sets a switch to indicate that an I/O 
error has occurred, and then returns = con- 
trol to the control program. The control 


program completes its processing and 
returns control to IHCDIOSH. IHCDIOSH 
interrogates the switch, finds it to be 


set, and passes control to the I/O error 
routine of IHCFCOMH. 


Write Section 


The write section of IHCDIOSH processes 
write requests. The write section may be 
entered either from the file initialization 
section of IHCDIOSH, or from IHCFCOMH. The 
processing performed by the write section 
depends upon where it is entered fron. 


PROCESSING IF ENTERED FROM FILE INITIALIZA- 
TION SECTION: If the write section is 
entered from the file initialization sec- 
tion of IHCDIOSH, no writing is performed. 
The write section only provides IHCFCOMH 
with buffer space in which to place the 
record to be written. The relative record 
number of the record to be written is 
inserted into the appropriate BLKREF field 
(i.e., BLKREFA or BLKREFB). (The record is 
written the next time the write section is 
entered.) For a formatted write, the buf- 
fer is filled with blanks. For an unfor- 
Matted write, the buffer is fillea with 
zeros. The write section then places the 
address of the buffer and the size of the 
buffer into registers for use by IHCFCOMH. 
Control is then returned to IHCFCOMH. 


PROCESSING IF ENTERED FROM IHCFCOMH: Each 
time the write section is entered from 
IHCFCOME, it writes the contents of the 


buffer onto the specified data set. Subse- 
quent write section processing for entran- 
ces from IHCFCOMH is the same as that 
described for entrances from the file ini- 
tialization section of IHCDIOSH (refer to 
"Processing If Entered From File Initiali- 
zation Section"). In addition, the asso- 
ciated variable is modified prior to 
returning to IHCFCOMH. The associated 
variable for the data set is updated so 
that it points to the relative position 
within the direct access data set of the 
record following the record just written. 


Note 1: The writing of physical records by 
this section is overlapped. That is, while 
IHCFCOMH is filling buffer A, buffer B is 
being written onto the output data set. 
When buffer A has been filled, the write 
from buffer B is checked for completion. 
Upon completion of the write operation, 
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IHCFCOMH starts placing data into buffer B. 


In addition, a write from buffer A is 
initiated. 

Note 2: If an 1/0 error occurs during 
writing, the control program returns con- 
trol to the synchronous exit routine 
(SYNADR) within IHCDIOSH. The SYNADR rou- 


tine sets a switch to indicate that an I/0 
error has occurred, and then returns con- 


trol to the control program. The control 
program completes its processing ana 
returns control to IHCDIOSH. IHCDIOSH 
interrogates the switch, finds it to be 
set, and passes control to the I/0 error 
routine of IHCFCOMH. 
Termination Section 

The termination section of IHCDIOSH 


receives control from the load module ter- 
Mination routine of IHCFCOMH. The function 
of this section is to terminate any pending 
I/O operations involving direct access data 
sets. The unit biocks associated with the 
direct access data sets are examined by 
IHCDIOSH to determine if any I/O is pend- 
ing. CHECK macro-instructions are issued 
for all pending I/O operations to insure 
their completion. 


The data control blocks for the direct 
access data sets are closed, and the main 
storage occupied by the unit blocks is 
freed via the FREEMAIN macro-instruction. 
Control is then returned to the load module 
termination routine of IHCFCOMH to complete 
the termination process. 


IHCIBERH 


IHCIBERH, a member of the FORTRAN system 
library (SYS1.FORTLIB), processes object- 
time source statement errors. THCIBERH is 
entered when an internal sequence number 
(ISN) cannot be executed because of a 
source statement error. 


The ISN of the invalid source statement 
is obtained (from information in the 
calling sequence) and is then converted to 
decimal form. IHCIBERH then links to 
IHCFCOMH to implement the writing of the 
following error message: 


IHC230I - SOURCE ERROR AT ISN 
XXXX - EXECUTION FAILED 
SUBROUTINE (name) 


After the error message iS written on 
the user-designated error output data set, 
IHCIBERH passes control to the IBEXIT rou- 
tine of IHCFCOMH to terminate execution. 


Chart 31 
of IHCIBERH. 


illustrates the overall logic 
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IHCDBUG 


IHCDBUG performs the object-time opera- 
tions of the Debug Facility statements. 
All linkages from the load module to 
IHCDBUG are compiler generated. 


Items and Buffer 
The following items in IHCDBUG are ini- 
tialized to zero at load time: 


DSRN - the data set reference number 
TRACFLAG ~- trace flag 

IOFLAG - input/output in progress flag 
DATATYPE - variable type bits 


Whenever information is assembled for 
output, it is placed in a 70-byte area 
called DBUFFER. Tne first character of 
this area is permanently set to blank, for 


Single spacing. 


Operation 


The first portion of IHCDBUG, called by 
entry name DEBUG#, is a transfer table; 
this table is referred to by the code 
generated for the Debug Facility state- 
ments, and branches to the thirteen section 
of IHCDBUG. These sections are discussed 
individually. 


TRACE ENTRY: 

routine exits. 
"TRACES are moved to 
subroutine OUTINT converts 
label to EBCDIC and places it in 
and a branch is made to OUTBUFFR. 


If TRACFLAG is off, this 

Otherwise, the characters 
DBUFFER + 1, the 
the statement 
DBUFFER, 


The characters ‘SUBTRACE‘ 
subprogram 
branch to 


SUBTRACE ENTRY: 
and the name of the program or 
are moved to DBUFFER and a 
OUTBUFFR is made. 


SUBTRACE RETURN ENTRY: The characters 
*"SUBTRACE ¥*RETURN** are moved to DBUFFER 
and a branch to OUTBUFFR takes place. 


UNIT ENTRY: The unit number argument is 
placed in DSRN and the routine exits. 


INIT SCALAR ENTRY: The data type is saved, 
the location of the scalar is computed, 
subroutine OUTNAME places the name of the 
scalar in DBUFFER, and a branch is made to 
OUTITEM. 


INIT ARRAY ELEMENT ENTRY: This routine 
saves the data type, computes the location 
of the array element, and (via the subrou- 
tine OUTNAME) places the name of the array 
in DBUFFER. It then computes the element 
number as follows: 


element number = ((element location - first 
array location) / element size) + 1 
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and places a left parenthesis, the element 
number (converted to EBCDIC by subroutine 
OUTINT), and a right parenthesis in DBUFFER 
following the array name. A branch is then 
made to OUTITEM. 


INIT FULL ARRAY ENTRY: If IOFLAG is on, 
the character X'FF' is placed in DBUFFER, 
followed by the address of the argument 
list, and a branch is made to OUTBUFFR. 
Otherwise, a call to the INIT ARRAY ELEMENT 
entry is constructed, and the routine loops 
through that call untii all elements of the 
array have been processed, when it exits. 


SUBSCRIPT CHECK ENTRY: The location of the 
array element is computed; if it is less 
than or equal to the maximum array loca- 
tion, the routine exits. If the array 
element location is outside the bounds of 
the array, the element number is computed 
and the characters "SUBCHK' are placed in 
DBUFFER. The subroutine OCUTNAME then plac- 
es the name of the array in DBUFFER, OUTINT 
supplies the EBCDIC code for the element 
number (which is enclosed in parentheses), 
and a branch is made to OUTBUFFR. 


TRACE ON ENTRY: TRACFLAG is turned on (set 
to non-zero) and the routine exits. 


TRACE OFF ENTRY: TRACFLAG is turned off 
(set to zero) and the routine exits. 


DISPLAY ENTRY: If IOFLAG is on, the char- 
acters ‘DISPLAY DURING I/O SKIPPED' are 
moved to DBUFFER anda branch is made to 


OUTBUFFR. Otherwise, a calling sequence 
for the NAMELIST write routine is con- 
structed. If DSRN is equal to zero, the 


unit number for SYSOUT (in IHCUATBL + 6) is 
used as the unit passed to the NAMELIST 
write routine. On return from the NAMFLIST 
write, this routine exits. 


START I/O ENTRY: The BYTECNT is set to 252 
to indicate that the current area is full, 
the IOFLAG is set to X'80' to indicate that 
input/output is in progress, the CURBYTLC 
is set to the address of SAVESTRT (where 
the location of the first main biock will 
be - refer to the description of ALLOCHAR), 
and the routine exits. 


END I/O ENTRY: The IOFLAG is saved in 
TEMPFLAG and IOFLAG is reset to zero so 


that this section may make debug calls 
which result in output to a device. If no 
information was saved during the 


input/output, this routine exits. 


subroutine FREECHAR is used to 
extract one character at a time from the 
Save area. If an X‘'FF*' is encountered 
(indicating the output of a full array), 
the next three bytes give the address of 
the call to INIT FULL ARRAY entry. A call 
to the DEBUG INIT FULL ARRAY entry is’ then 
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constructed and executed. If X'FF" is not 
encountered, characters are placed in DBUF- 
FER until an X'15‘ is found, indicating the 
end of a line. When this code is found, 
the subroutine OUTPUT is used to write out 
the line. 


If no main storage or insufficient main 
storage was available for saving informa- 
tion during the input/output, the charac- 
ters "SOME DEBUG OUTPUT MISSING‘ are placed 
in .DBUFFER after all saved information (if 
any) has been written out. The subroutine 
OUTPUT is then used to write out the 
message, and this routine returns to the 
caller. 


Subroutines 


The following subroutines 
the routines in IHCDBUG. 


are used by 


OUTITEM: First, the characters ' = '* 
moved to DBUFFER. 
the data to be output 
branch on type then takes place. For fixed 
point, the routine OUTINT converts the 
value to EBCDIC and places it in DBUFFER. 
A branch to OUTBUFFR then takes place. 


are 
The routine then loads 
into registers. A 


For floating values, subroutine OUTFLOAT 
places the value in DBUFFER. A branch to 
OUTBUFFR then takes place. 


For complex values, two calls to OUT- 
FLOAT are made ~- first with the real part, 
then with the imaginary part. A left 
parenthesis is placed in DBUFFER before the 
first call, a comma after the first call, 
and a right parenthesis after the second 
call. A branch to OUTBUFFR then takes 
place. 


For logical values, a T is placed in 
DBUFFER if the value was non-zero; other- 
wise an F is placed in DBUFFER. A branch 
to OUTBUFFR then takes place. 


OUTNAME: This is a closed subroutine. Up 
to six characters of the name are placed in 
DBUF FER. However, the first blank in the 





name causes the routine to exit. 


OUTINT: This is a closed subroutine. If 
the value (passed in R2) is equal to zero, 


the character '0" is placed in DBUFFER and 
the routine exits. If it is less than 
zero, a minus Sign is placed in DBUFFER. 


The value is then converted to EBCDIC and 
placed in DBUFFER with leading zeros’ sup- 
pressed. The routine then exits. 


OUTFLOAT: This is a closed subroutine. If 
the value is zero, the characters '0.0E+00' 
or ‘0.0D+#00° are placed in DBUFFER, depend- 
ing upon whether the value is single or 
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double-precision, respectively, and the 
routine exits. If the values are less than 
zero, a minus Sign is placed in DBUFFER. 
The floating number is then converted to a 
String of decimal EBCDIC characters and a 
power of ten by exactly the same algorithm 
used in IHCFCUTH (this assures identical 
results). 


If 


Let x 8 for single-precision, 


x 17 for double-precision. 

If 1<|value|<10 , it is output to the 
DBUFFER in Fxti.x-n format where n is 
the integer portion of log |valuej|. 


Otherwise it is output in G x+5.x format. 
The routine then exits. 


OUTBUFFR: If IOFLAG is not set, the rou- 
tine calls the subroutine OUTPUT and then 
exits. Otherwise, IOFLAG is set to indi- 
cate that debug output during input/output 
occurred. Then, a call is made to ALLOCHAR 
for each character in DBUFFER, and finally, 
a call to ALLOCHAR with X'15" indicating 


the end of the line. The routine then 
exits. 
ALLOCHAR: This is a closed subroutine. If 


BYTECNT is equal to 252, indicating the 
current block is full, a new block of 256 
bytes is obtained by a GETMAIN macro. If 
no storage was available, an X‘'07', indi- 
cating end of core, is placed in the last 
available byte position, IOFLAG is set to 
full, and the routine exits. Otherwise, 
the address of the new block is placed in 
the last three bytes of the previous block, 
preceded by X'37" indicating end of block 
with new block to follow. CURBYTLC is then 
set to the address of the new block and 
BYTECNT is set to zero. The character 
passed as an argument is then placed in the 
byte pointed to by CURBYTLC, one is added 
to both CURBYTLC and BYTECNT, and the 
routine exits. 


FREECHAR: This is a closed subroutine. If 
the current character extracted is X'37', 
the next three bytes are placed in CURBYTLC 


and the current block is freed. If the 
current character is X‘07' the block is 
freed and a branch to the End I/O exit is 


taken. Otherwise, the current character is 
passed to the calling routine and CURBYTLC 
is incremented by 1. 


OUTPUT: This is a closed subroutine. If 
DSRN is zero, the SYSOUT unit number is 
obtained from IHCUATBL + 6. A call is then 
made to FIOCS# output initialize, DBUFFER 
is transferred to the FIOCS# buffer, and a 
call is made to FIOCS# output. The routine 
then exits. 
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Chart 24. IHCFCOMH Overall Logic and Utility Routines 
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25. Implementation of READ/WRITE/FIND Source Statements 
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THIS CALL IS 
GENERATED 38Y 
CQMPIYLER WHEN 
I/GQ LIST ITEM 
IS ENCOUNTERED. 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 

ALL 1/70 LIST ITEMS 
ARE PROCESSEDe 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 
I/O LIST ITEM 
IS ENCOUNTERED. 


THIS CALL IS 
GENERATED BY 
COMPILER WHEN 

ALL 1/0 LIST ITEMS 
ARE PROCESSEDe 
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Chart 26. Device Manipulation, Write-to-Operator, and READ/WRITE Using NAMELIST Routines 
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T 


os ee es a se a ee 


abie 33. IHCFCOMH Subroutine Directory 
i se in ria ia wi aka ee ma ae a Sa pce ig ee es a 7 
[Subroutine] Function | 
EXCEPT |Checks for presence of END= parameter, and passes control to the load module| 
Jif present. | 
FENDF {Closing section for a READ or WRITE requiring a format. | 
FENDN |Closing section for a READ or WRITE not requiring a format. | 
FEOFM {Implements the END FILE source statement. | 
FERROR |Checks for the presence of the ERR= parameter, and passes control to the] 
{load module if present. | 
FIOAF {I/O list section for list array of a READ or WRITE requiring a format. | 
FIOAN JI70 list section for list array of a READ or WRITE not requiring a format. | 
FIOLF |I70 list section for a list variable of a READ or WRITE requiring a format. | 
FIOLN JI/7O list section for a list variable of a READ or WRITE not requiring a| 
| format. | 
FPAUS jimplements the PAUSE source statement. | 
FRDNF {Opening section of a READ not requiring a format. | 
FRDWF |Opening section of a READ requiring a format. | 
FRWND {Implements the REWIND source statement. | 
FSTOP |Implements the STOP source statement. | 
FWRNF }Opening section for WRITE not requiring a format. | 
FWRWE {Opening section for WRITE requiring a format. | 
IBEXIT |Closes all data sets and terminates execution. | 
IBFERR |Processes object-time errors. | 
IBFINT |Processes arithmetic-type program interruptions. | 
FBKSP Lee the BACKSPACE source statement. | 
a Mh a a ra Sd ST ee 4 

able 34. IHCFCVTH Subroutine Directory 
Sa a a a a se a ee ee eS 4 
| Subroutine] Function | 
are a a a a a i eS le a ee 4 
FCVAI |Reads alphameric data. | 
FCVAO |Writes alphameric data. | 
FCVCI {Reads complex data. { 
FCVCO {Writes complex data. | 
FCVDI {Reads double precision data with an external exponent. | 
FCVDO {Writes double precision data with an external exponent. | 
FCVEI [Reads real data with an external exponent. | 
FCVEO [Writes real data with an external exponent. | 
FCVFI [Reads real data without an external exponent. | 
FCVFO |Writes real data without an external exponent. | 
FCVGI [Reads general type data. | 
FCVGO {Writes general type data. | 
FCVII |Reads integer data. | 
FCVIO |Writes integer data. | 
FCVLI {Reads logical data. | 
FCVLO {Writes logical data. | 
FCV21 |Reads hexadecimal data. | 
FCVZO {Writes hexadecimal data. | 
era races ae vaere a a a ea ee 
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Chart 27. 
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Chart 30. IHCDIOSH Overall Logic - File Initialization, Read, Write, and Termination 
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Table 35. 


IHCFIOSH Routine Directory 


Ce re nS ee er ee ap ee et a a tye a ey ee ee 1 
| Routine | Function | 
i ah a i a aN NN tg ah Ta ek le eh eee | 
| FCLOS |CHECKs double-buffered output data sets. | 
| | 
| FCNTL |Services device manipulation requests. | 
| | | 
| FINIT JInitializes unit and data set. | 
| | | 
| FREAD |Services read requests. | 
| 
| FRITE |Services write requests. : | 
sere Ae Sena a ae eee aa ae ea Sa nae Se a ee ea eae ee se ee eee ee J 
Table 36. IHCDIOSH Routine Directory 
Bree ee ee ee an, ag ee a eye Gg eee Pee gr ee a eee 7 
{| Routine | Function 
[---------- | Sag peep = ndgn clad a ce oe ena PERE RENEE eee 
| DASDEF |Processes DEFINE FILE statements: enters address of parameter lists into} 
| junit assignment table, checks for redefinition of direct access unit| 
| jmunbers, and establishes addressability for IHCDIOSH within IHCFCOMH. | 
| | 
|DASINIT |Constructs unit blocks for nonopened direct access data sets, creates ana| 
| jformats new direct access data sets, and opens data control biocks for| 
| |direct access data sets. | 
| | 
| DASREAD jReads physical records, passes buffer pointers and buffer size to IHCFCOMH, | 
| jand updates the associated variable. | 
| | | 
| DASTERM |Checks pending I/O operations, closes direct access data sets, and frees| 
| Jmain storage occupied by unit blocks. | 
| | | 
| DASTRA |Determines operation type and transfers control to appropriate routine. | 
| | | 
|DASWRITE |Writes physical records, provides IHCFCOMH with buffer space, and updates| 
| {the associated variable. 
boeceesieoe SN a a a Ba a re te a es ee J 
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Chart 31. IHCIBERH Overall Logic 
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APPENDIX F: 


Data references in the form of sub- 
scripted variables expressions in FORTRAN 
are converted into object code that 
includes address arithmetic and indexed 
references to main storage addresses. 
Since the conversion involves all phases of 
the compiler, a summary of the method is 
given here. 


Consider an array A of n dimensions 
whose element length is L, and whose dimen- 
Sions are Di, D2, D3, ...-,Dn. If such an 
array is assigned main storage starting at 
the address P11, then the element A(J1, J2, 
J3,---,0n) is located at 


P = P11 + (J1-1)*L + (J2-1)*D14*L + 
(33-1) *D1*D2*L + 2... + (Jn-1)*D1*D2+*D3* 


This may be expressed as: 


P = POO + J1*L + J2*(D1*L) + J3*(D1*D2*L) 
+ ... + Jn*(D14#D2*D3* ... *D(n-1) *L) 


where 


POO = Pil - (D1*L + D1*D2*L + 1... +) 
D1*D2* ... *D(n-1)*L) 


For fixed dimensioned arrays, the quan- 
tities Di*L, D1*D2*L, D1*D2*D3*L, ... , 
which are referred to as dimension factors, 
are computed at compile time. The sum of 
these quantities, which is referred to as 
the span of the'array, is also computed at 
compile time. (Phase 15 assigns an array a 
relative address equal to its actual rela- 
tive address minus the span of the array.) 


In the object code, P is finally formed 
as the sum of a base register, an index 
register, and a displacement. The phase 15 
segment CORAL associates an address con- 
stant with each fixed dimensioned array 
such that Pa<P00<Pat4095, where Pa is the 
address inserted into the address constant 
at program fetch time. The effective 
address is then formed using a base reg- 
ister containing the address constant, a 
displacement equal to P00 - Pa, and an 
index register, which contains the result 
of a computation of the form: 


ce 2,01 

SLL 2,logaL 
L 1,02 

M 0,L*D1 

AR 254 

i 1,33 

M 0,D1*D2*L 


Appendix F: 


ADDRESS COMPUTATION FOR ARRAY ELEMENTS 


AR 21. 

L 1,dJn 

M 0,D1*D2*...*D(n-1) 
AR 2,1 


Absorption of Constants in Subscript 
Expressions 


Subscript expressions imay include con- 
stant parts whose contribution to the final 
effective address is computed at compile 
time. For example, 


B(I-2,3+4,3*5- (L+7)-6) 
would usually be treated in such a way that 
the effect of the 2, the 4, and the 6 would" 
be absorbed into the displacement at com- 
pile time. 

Consider an example of the form 
A(J1+K1,J92+K2, ... ,Jnt+Kn), 
where A is a fixed dimensioned array and 


Kl ,-, K2;. was , Kn are integer constants. 
Phase 15 will insert the quantity 


K1i*L + K2*(D1*L) + K3*(D1*D24L) + 


eee + Kn(D1*D2* 1... *D(n-1)¥*L) 
into the displacement (DP) field of the 
corresponding subscript or load address 
text entry. The constants will not other- 
wise be included in the subscript expres- 
sion. When phase 25 generates machine 
code, the contents of the DP field are 


added to the displacement. To ensure _ that 


the resultant expression lies within the 
range of 0 to 4095, phase 20 performs a 
check. If the result is not in the range, 


a dictionary entry is reserved for the 
result of the addition, and a suitable add 
text entry is inserted to alter the index 
register immediately before the reference. 


Arrays as Parameters 


When an array is used aS an argument, 
the location of its first element, Pili, is 
passed in the parameter list. The prologue 
of the called subroutine contains machine 
code to compute the corresponding P00 loca- 
tion. When an array has variable dimen- 
sions, no constant absorption takes place 
and the dimension factors are computed for 
each reference to the array. 
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APPENDIX G: COMPILER STRUCTURE 


The FORTRAN IV (H) 
tured in a planned 
planned overlay structure is a single 


compiler is struc- 
overlay fashion. A 
load 


module, created by the linkage editor in 
response to overlay control statements. 
These statements, a description of a 


planned overlay structure, and instruction 
in specifying such a program structure are 
presented in the publication IBM System/360 
Operating System: Linkage Editor. The 
processing performed by the linkage editor 
in response to the overlay control state- 
ments is described in the publication IBM 


System/360 Operating System: Linkage Edi- 
tor, Program Logic Manual. 


The compiler's pianned overlay structure 
consists of 20 segments, one of which is 
the root. The root segment contains the 
ymajor portion of the FSD and includes the 
processing units (e.g., the compile-time 
input/output routines) and data areas 
(e.g., communication region) that are used 
by two or more compiler phases. The root 
segment remains in main storage throughout 
execution of the compiler. 


Each of the remaining 19 
except for segment 2, constitutes a phase, 
or a logical portion of a phase. (Segment 
2 is part of the FSD, and its function is 


segments, 


to aid in the deletion of a compilation.) 
Phase segments are overlaid as compiler 
1 (155)* 
2 (.35) Se ee 
5 (1.5) 
4 (10) 
6 6.5) 
9 (13.5) 
8 (26.5) 
13 (17) 


14 (26) 


15 (49.5) 


10 (42.5) 


7 (67.5) 
3 (76) 11 8) 12 (7) 


* The number in parentheses times 1,000 equals the approximate segment length 
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processing requires the services of another 
segment. 

Figure 65 illustrates the compiler's 
planned cverlay structure. In the figure, 
each segment is identified by number. Seg- 
ments associated with vertical line origi- 
nating from the same horizontal line over- 
lay each other as needed. The figure also 
indicates the approximate size (in bytes) 
of each segment. 


The longest path? of this structure is 
formed by segments 1 and 3 because, when 
they are in main storage, the compiler 
requires approximately 231,000 bytes. 
Thus, the minimum main storage requirement 
for the compiler is approximately 231,000 
bytes. 


The linkage editor assigns the relocata- 
ble origin of the root segment (the origin 
of the compiler) at 0. The relocatable 
origin of each segment is determined by 0 
plus the length of all segments in the 
path. For example, the origin of segment 
19 is equal to 0 plus the length of segment 


1 plus the length of segment 5 plus’ the 
length of segment 18. 
1A path consists of a segment and alli 
segments between it and the root segment, 
and including the root segment. 
18 (11) 
17 (20.5) 


16 (9.5) 


19 (20) 


20 (58) 


The segments that constitute each of the 
compiler phases are outlined in Table 37. 
The remainder of this appendix is devoted 
to a discussion of the segments of the 
compiler's planned overlay structure. 


Table 37. Phases and Their Segments 


|Phase 10|Segments 3 

|Phase 15|[Segments 4, 5, 6, 7, and 8 
{Phase 20|Segments 6, 9, 10, 11, 12, 13, 

| | 14, 15, and 16 

{Phase 25]Segments 18, 19, and 20 

{Phase 30|Segment 17 

}-------- Ne lees a ome ti ee Sea re 
jNote: Segment 6 is considered a portion| 
[cf both Phases 15 and 20. It contains| 
[data areas used by both phases. | 


coches eames comes tems meme mene ema conf 


Segment 1: This segment is the root of the 
compiler's planned overlay structure. Seg- 
ment 1 is the FSD. It has a relocatable 
origin at zero. Segment 1 is not overlaid. 
The composition of segment 1 is illustrated 
“in Table 38. 


Table 38. Segment-1 Composition 

Porc oon ie ee Er Oe oe eee 1 
| Control Section | Entry Point(s) | 
[--------------------- 1------~------------ { 
| S$SEGTAB | 
| BLANK | 
| ADCON | 
| ERCOM | 
| IEKFCOMH IBCOM | 
i IBCOM# | 
| TEKFIOCS FIOCS | 
| FIOCS# i 
i IEKAAO01 { 
| AFRXPI FRXPI# | 
| FRXPI | 
H SYSTAB SYSTAB | 
| IEKAA00 GETCOR | 
| ENDFILE { 
| SYSDIR | 
| PAGE j 
| SYSTRC SYSTRC | 
| IHCFMAXT MAXO | 
| MINO | 
| AMAX0 | 
| AMINO | 
| THCFMAXR MAX1 | 
| MINI | 
| AMAX1 { 
| AMIN1 | 
| REWIND REWIND | 
i PUTOUT PUTOUT | 
Dee ie a en ee J 
Segment 2: This segment is a portion of 
the FSD. It contains only one routine, 
IEKAREAD. IEKAREAD is executed if it 
becomes necessary to delete a compilation 
during phase 10 processing. ( TEKAREAD 


scans the remaining source statements until 


the END statement is recognized.) The 
origin of segment 2 is immediately after 
segment 1. If it becomes necessary to 


deiete a compilation during phase 10 proc- 
essing, segment 2 overlays segment 3. Seg- 
ment 2 is then overlaid by segment 3 when 
the next compilation is initiated. The 
composition of segment 2 is illustrated in 
Table 39. 


Table 39. Segment-2 Composition 

[Poe gee ee Tossa eee 1 
{| Control Section | Entry Point | 
}-----~-—~----------- =~ —— =~ =~ — =~ { 
| IEKAREAD IEKAREAD | 
Cae Stace eee eee et eee ae J 
Segment 3: This segment iS phase 10. The 


origin of this segment is immediately after 
segment 1. If it becomes necessary to 
delete a compilation during phase 10 proc- 
essing, segment 3 is overlaid by segment 2, 
and after segment 2 is executed, segment 3, 
in turn, overlay segment 2 when the next 
compilation is initiated. If a compilation 
is not deleted during phase 10, segment 3 
is overlaid by segment 4. The composition 
of segment 3 is iliustrated in Table 40. 


Table 40. Segment-3 Composition 


XARITH 
ACLASS 


For GENDO and the re- 
maining control sec- 
tions of this segment 
the control section 
names and the entry 
point names are the 
same. 


| 

| 

| 

| 

| 

| 

| 

| 

| 

RTPROT | 
XPUSE | 
LITCON | 
GETCD | 
XGO | 
XEQUI l 
DSPTCH 
XNMLST | 
CSORN | 
GRPKEQ | 
PERLOG | 
XDO | 
CDOPAR | 
XDATA | 
XBCKRW l 
XIMPD | 
SYMTLU l 
XEXT | 
XFMT | 
LABTLU | 
MINSLS 
XEND | 
XIF 
4 


a a en em em a ee a a a ee ae cre ee ee ee a ee re ee 


(Continued) 
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Table 40. Segment-3 Composition (Cont.) 


c T 
| Control Section | Entry Point(s) | 


—- 
| 
1 
1 
| 
| 
| 
| 
t 
| 
| 
! 
! 
I 
| 
| 
| 
| 
! 
! 
| 
K 
1 
! 
! 
! 
{ 
| 
| 
| 
' 
{ 
i 
! 
! 
! 
! 
! 
| 
! 
! 
I 

te 


PUTX 
TXTBLD 
XIOOP 
XRETN 
XSUBPG 
XBLOK 
XIMPC 
XTYPE 
XDIM 
XCOMON 
XASF 
XASF2 
XASGN 
XSTRUC 


Pe ee ce ee ee ee ee ee ee ee ee ee ee oe 
hanes eneee SRI SAD SS GREED MNES SE OS SEN EN ES GN neon SOS cS GO ee eS 


Segment 4: This segment is a portion of 
phase 15. It contains the subroutines that 
sort the dictionary, and process COMMON and 
EQUIVALENCE declarations. The origin of 
segment 4 is immediately after segment 1 
(the root segment). Segment 4 overlays 
segment 3, and is overlaid by segment 5. 
The composition of segment 4 is illustrated 
in Table 41. 


Table 41. Segment-4 Composition 


}----~~-------------- 1---~~-~------------- { 
| LABSCN For this segment, | 
| DCTSRT control section | 
| COMN names and entry | 
| EQU point names are the | 
| SBEROR same. | 
| STALL | 
| BSIZE | 
| TESTBN | 
ote a ee Se J 
Segment 5: This segment is a portion of 
phase 15. It contains the subprogram table 
(IFUNTB), which is used by both the PHAZ15 


and CORAL segments of phase 15. 
of segment 5 is immediately after segment 
1. Segment 5 overlays segment 4. The 
composition of segment 5 is illustrated in 
Table 42. 


The origin 


Table 42. Segment-5 Composition 

pattie a + 
| Control Section | Entry Point(s) | 
}——~ -—- =~ =——-— 1-—~~———-——~-—-----— { 
| IFUNTB | 
Geese Doe ie eta Se Sa eee ae J 
Segment 6: This segment is considered a 


portion of both phases 15 and 20. It 
contains data areas that are used by both 
these phases. Included in this segment are 
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RMAJOR, CMAJOR, the full register assign- 
ment tables, and phase 15/20 work areas. 
The origin of segment 6 is immediately 
after segment 5. Segment 6 is overlaid by 
segment 18, if abortive errors are not 
encountered during the processing of phases 
10 and 15. The composition of Segment 6 is 
illustrated in Table 43. 


Table 43. Segment-6 Composition 
| Control Section | Entry Point(s) | 
ee sie eS Lo 5 
| C1520 | 
| RMAJOR | 
ee ee ee ee eee ea J 
Segment 7: This segment is a portion of 
phase 15, It contains the subroutines that 
implement the PHAZ15 functions of that 
phase, which are arithmetic translation, 


text blocking, and information gathering. 
The origin of segment 7 is immediately 
after segment 6. Segment 7 is overlaid by 
segment 8. The composition of segment 7 is 
illustrated in Table 44. 


Table 44. Segment-7 Composition 


T 1 
| Control Section | Entry Point (s) i 


}---------~------+--- 4———~~---~--~~------- { 
| SUBSCR SUBSCR | 
| PH15 | 
| MATE MATE | 
| STTEST STTEST | 
| BLTNFN BLTNFN | 
| DUMP15 DUMP15 | 
| EXPON EXPON | 
| ANDOR ANDOR 
| CPLTST CPLTST | 
| PHAZ15 PHAZ15 
| SUBMLT SUBMLT | 
| GENRTN GENRTN | 
| LOOKER | 
| ALTRAN ALTRAN | 
| MODTST MODTST | 
| XPARAM XPARAM | 
| DFUNCT DFUNCT | 
| RELOPS RELOPS | 
| FINISH FINISH | 
| PAREN PAREN | 
| LIBRTN LIBRTN | 
| TXTREG TXTREG | 
| GENER GENER 
| RDTST RDTST | 
| GETEXT GETEXT | 
| ARIF ARIF | 
| NEGCHK NEGCHK | 
| UNARY UNARY | 
| GMAT GMAT | 
| TXTLAB TXTLAB | 
| VSETUP VSETUP | 
| WRIT15 WRITI5 | 
| MNE | 
Bae a ye J 

(Continued) 


Table 44. Segment-7 Composition (Cont.) 

| Control Section | Entry Point(s) | 
[---------~---------- bean nnnnan { 
| SBGLUT SBGLUT | 
| FUNDRY FUNDRY | 
| SUBADD SUBADD | 
| MODIFY MODIFY | 
| NOT NOT i 
| OP1CHK OP1CHK | 
| POWER2 POWER2 { 
{ COMMD COMMD | 
| NSTRNG NSTRNG { 
| SWITCH SWITCH | 
| CNSTCV CNSTCV { 
tee SoS oe ee a ee es J 
Segment 8: This segment is a portion of 


phase 15. It contains the subroutines that 
implement the CORAL functions of the phase. 
The origin of segment 8 is immediately 
after segment 6. Segment 8 overlays seg- 
ment 7. Segment 8 is overlaid by segment 
9, if syntactical errors are not encoun- 
tered by phases 10 and 15. If errors are 
present, segment 8 is overlaid by segment 
17. The composition of segment 8 is illus- 
trated in Table 45. 


Table 45. Segment-8 Composition 

6a nee Se ep ee ee 
| Control Section | Entry Point(s) | 
-}-------------------- 4——-~—-—~~—-——~~---~---~ 4 
| EXTRNL EXTRNL | 
| STMAP 2 | 
{ NDATA For NDATA and the | 
| VARA remaining control | 
| CORAL sections of this | 
| TESTWD segment, the control| 
{ EQVAR section names and | 
| CONST entry point names | 
| CMSIZE are the same. | 
| COMVAR | 
| ADSCAN | 
i DATACH | 
| ERDATA | 
| SIZE | 
| PRTEXT | 
| SPAN | 
| CORLDT | 
r PHSTAL | 
BS a ee J 


Seqment 9: This segment is a portion of 
phase 20. It contains the 
subroutine of that phase, the Loop selec- 
tion routines, and a number of frequently 
used utility subroutines. The origin of 
segment 9 is immediately after segment 6. 
Segment 9 overlays segment 8, if source 
module errors are not encountered by phases 
10 and 15. If errors are encountered, 
segment 9 overlays segment 17 after its 


processing is completed, only if the errors — 


encountered are not serious enough to cause 
the deletion of the compilation. The com- 
position of segment 9 is illustrated in 
Table 46. 


controlling 


Table 46. Segment-9 Composition 

freee nets eee ee eee 
| Control Section | Entry Point (s) | 
ee a ee a { 
| . CNT | 
| OPT | 
| GETDIK ‘“GETDIK | 
| GETDIC GETDIC | 
| LPSEL LPSEL | 
| NPRFUN NPRFUN | 
| INVERT INVERT | 
| GETSPC GETSPC | 
| FILTEX FILTEX | 
| TARGET TARGET ~ { 
| BASVAR BASVAR | 
| BSYONX BSYONX | 
Dee ah ae i he gk J 
Segment 10: This segment is a portion of 
phase 20. It contains the subroutines that 


perform common expression elimination and 
strength reduction as well as the major 
portion of the utility subroutines used 


during text optimization. 
executed only if the 
path through phase 20 is 
origin of segment 10 is immediately after 
segment 9. During the course of complete 
optimization, segment 10 overlays segment 
14. Segment 10 is overlaid by segment 15 
after all module loops have been text- 
optimized. The composition of segment 10 
is illustrated in Table 47. 


Segment 10 is 
complet e-optimized 
specified. The 


Segment 11: This segment is a portion of 
phase 20. It contains the routines’ that 
perform forward and backward movement. The 
origin of segment 11 is immediately after 
segment 10. The composition of segment 11 
is illustrated in Table 48. 


Segment 12: This segment is not executed 
in this version of the compiler. 


Segment 13: This segment is a portion of 
phase 20. It consists of the subroutines 


that perform basic register assignment. 
Segment 13 is only executed in the non- 
optimized path through phase 20. The 
origin of segment 13 is immediately after 
segment 9. Segment 13 does not overlay any 
other segment in phase 20, nor is it 
overlaid by another segment in phase 20. 
The composition of segment 13 is illustrat- 
ed in Table 49. 


Segment 14: This segment is a portion of 
phase 20. It consists of the subroutines 


that determine (1) the back dominator, back 


target, and loop number of each source 
module block, and (2) the busy-on-exit 
data. Segment 14 is only executed if the 


complete-optimized path through phase 20 is 


followed. This segment is only executed 
once and is overlaid by segment 10. The 
origin of segment 14 is immediately after 


segment 9. The composition of segment 14 
is illustrated in Table 50. . 
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Table 47. Segment-10 Composition 

{ Control Section | Entry Point(s) 

bo a eee a ee es 
| NORMIZ NORMIZ 

| MOV 

| REDUCE REDUCE 

| MOZ 

| PARFIX For PARFIX and the 

| SUBACT remaining control 

| CLASIF sections, the con- 

| SUBTRY trol section names 

| SUBSUM and entry point 

| PERTRY names are the same. 
| MODFIX 

| LORAN 

| PERFOR 

| MOVTEX 

| OBTAIN 

| XSCAN 

| XPLACE 

| YSCAN 

| ZSCAN 

| MBRAN 

CIRCLE 

| DELTEX 

| XCHANG 

| XPELIM 

| KORAN 

| FOLLOW 

| XPELOC 

| TYPLOC 

| WRITEX 

{ INDTRY 

| INERT 

A Sa ata a ang a ee a i 
Table 48. Segment-11 Composition 

| Control Section | Entry Point(s) 
}------------+---+~-----1--~--~-~~+~-~~--+~~-~- 
| YCHANG YCHANG 

| BACMOV BACMOV 

| ZCHANG ZCHANG 
YPLACE YPLACE 

| ZPLACE ZPLACE 

| FORMOV FORMOV 

es Sari ae ee anes en ope 
Table 49. Segment-13 Composition 

{| Control Section | Entry Point(s) 

| TALL TALL 

i SPLRA SPLRA 

| SSTAT SSTAT 

a a se a ee A 
Table 50. Segment-14 Composition 

| Control Section | Entry Point(s) 
-----~~--------~--~--41~-~~~-~~-~---~--~--- 
| BAKT BAKT 

i BLK . 

| SRPRIZ SRPRIZ 

| TOPO TOPO 

| BIZX BIZX 


Segment 15: This segment is a portion of 
phase 20. It contains full register 


assignment subroutines and the utility sub- 
routines used by them. Segment 15 is 
executed in both the intermediate-optimized 
and complete-optimized paths through phase 
20. In the intermediate-optimized path, 
segment 15 is overlaid by segment 16. 
During complete-optimization, segment 15 
overlays segment 12 after all loops have 
been text-optimized and is overlaid by 
segment 16 after all loops have undergone 
full register assignment. The origin of 
segment 15 is immediately after segment 9. 
The composition of segment 15 is iliustrat- 
ed in Table 51. 


Table 51. Segment-15 Composition 

PS oe eS ee ee he ee ee 1 
| Control Section | Entry Point (s) | 
}--------------~--~--4--~-------~--------- { 
| REGAS REGAS | 
| REG | 
| PROP1 PROP1 | 
| BKP | 
| LOC | 
| FWDPAS FWDPAS | 
| FWP | 
| BKPAS BKPAS | 
| GTBASE GTBASE | 
| ALLCOR ALLCOR | 
| STX | 
| GLOBAS GLOBAS | 
| FCLT50 FCLT50 | 
| STXTR STXTR | 
| GLS | 
| MRCLEN For MRCLEN and the _ | 
| CXIMAG remaining control | 
| FWDPS1 sections, the con- | 
| HILOWS trol section names | 
| SETUP and entry point | 
| GLOBS1 names are the same. | 
| ACCEPT | 
| DISCHK | 
| SEARCH | 
| FREE | 
| SHARE | 
| TRNSFM | 
| SETREG | 
| RELCOR | 
I PRELUD | 
| BKDMP | 
ce a gt a i ee cat Ie J 


Seqment 16: This segment is a portion of 
phase 20. It consists of tne subroutines 
that 1) calculate the size of each text 
block and 2) determine which text blocks 


can be branched to via RX-format pranch 
instructions. Segment 17 is executed in 
both the intermediate-optimized and 


complete-optimized paths. Segment 16 over- 
lays segment 15 after full register assign- 
ment iS completed. Segment 16 is not 
overlaid within phase 20. The origin of 
segment 16 is immediately after segment 9. 
The composition of segment 16 is illustrat- 
ed in Table 52. 


Table 52. Segment-16 Composition 


aia aren ene cae a RG me aaa cd a 1 
| SEG4 SEG4 | 
| BLS BLS | 
| LYT LYT | 
| BLSDTA | 
| BSTRIP | 
bo So a es Se a ee Se ee ee J 


Seqment 17: This segment is phase 30. The 
origin of segment 17 is immediately after 
segment 6. Segment 17 overlays segment 8, 
if syntactical errors are encountered dur- 
ing the processing of phases 10 and i5. If 
the errors detected by these phases are not 
serious enough to cause deletion of the 
compilation, segment 17, after its process- 
ing is completed, is overlaid by segment 9. 
The composition of segment 17 is illustrat- 
ed in Table 53. 


Table 53. Segment-17 Composition 

{ Control Section | Entry Points(s) | 
[----~---------------4-------------------- { 
| IEKP30 IEKP30 | 
| MSGWRT MSGWRT | 
Mee ta ar a eS J 


Segment 18: This segment is a portion of 
phase 25. It contains a number of subrou- 
tines that are employed by both the initial 
text information construction and the text 
conversion portions of phase 25 (see Charts 


21 and 22). The origin of segment 18 is 
immediately after segment 5. Segment 18 
overlays segment 6. The composition of 


segment 18 is illustrated in Table 54. 


Table 54. Segment-18 Composition 

(Soe ee ea er 1 
{| Control Section | Entry Points(s) | 
}-------------------- 4—--—----—---------=- { 
| FAZ25 | 
| BXHCOM { 
| PROLOG PROLOG | 
| DCLIST DCLIST | 
| LISTER LISTER | 
| END END | 
| LABEL LABEL | 
| IEKTLOAD ESD | 
| TXT | 
| RLD | 
| IEND | 
| INITIA INITIA | 
| PACKER PACKER | 
| EPILOG EPILOG | 
| SENTAB | 
Pe Se Se oe eee Se SS Se ee eS J 


Segment 19: This segment is a portion of 
phase 25. It contains most of the suprou- 
tines that perform initial text information 
construction (see Chart 21.) The origin of 
segment 19 is immediately after segment 18. 
Segment 19 is overlaid by segment 20. The 
composition of segment 19 is illustrated in 
Table 55. 


Table 55. Segment-19 Composition 

pat eee ee ee ee eee 
| Control Section | Entry Point (s) | 
}---~-~-----—--------L------- ~~ == | 
| NADOUT For this segment, | 
| SUBR the control section {| 
| ATTACH names and entry | 
| FORMAT point names are the | 
| INITIL same. | 
| LYT1 | 
| DATOUT | 
| NLIST | 
(25s e Sa ae eae eee Se ee eee ee J 
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Segment 20: This segment is a portion of 
phase 25. It contains the subroutines that 
perform text conversion (see Chart 22). 
The origin of segment 20 is immediately 
after segment 18. Segment 20 overlays 


segment 19. The composition of segment 20 
is illustrated in Table 56. 
& 


Table 56. Segment-20 Composition 

poo nnn + 
| Control Section | Entry Points(s) | 
p-—-~-~— ~~~ bn nnn nnn : 
| MANGN2 MANGN2 { 
| DBLGEN DBLGEN | 
| IOSUB IOSUB | 
| LBITTF LBITTF i 
i BRCOMB BRCOMB | 
| FLTGEN FLTGEN | 
| DIMGEN DIMGEN | 
| TSTSET TSTSET | 
| NTFXGN NTFXGN | 
| RETURN RETURN | 
| BIVGEN DIVGEN | 
| MAINGN MAINGN | 
| CGEN | 
| STRGEN For STRGEN and the | 
| SHFT2 remainder of this { 
| IOSUB2 segment, the control| 
| CALLER section names and | 
| ITEKWAG entry point names | 
| TENTXT are the same. | 
a ONS Svea PS Pe reper ep J 


(Continued) 


220 


Table 56. 


Segment-20 Composition (Cont.) 


LDADDR 
BRCOMP 
STOPPR 
BRLGL 

BRANCH 
BTBF 

LGLNOT 
LDBGEN 
ENTRY 
SIGNGN 
ABSGEN 
GOTOKK 
LSTGEN 
SUBGEN 
MXMNGN 
LOGCL 
FNCALL 
CMPLGN 
ADMDGN 
NDORGN 
MOD 24 

BITNFP 
SHFTRL 
PLSGEN 
MINUS 

INTMPY 
UNRGEN 
MODGEN 


as cee ene ceeene cave Saemce SHE ORE eitmee Gee ees cee See SE cee SE cee ome Se eee Se ee ee ee ee ee ee ee ee he 


The messages produced by the compiler 
are explained in the publication IBM 
System/360 Operating System: FORTRAN IV 
Programmer's Guide. Each message is iden- 
tified by an associated number. The fol- 
lowing table associates a message number 
with the phase and subroutine in which the 


corresponding message is generated. 


As part of its processing of errors, 
whenever the compiler encounters an error 
that is serious enough to cause deletion of 
a compilation, it prints out a value, m, 
for the PHASE SWITCH (refer to Appendix C 


Sa crac asciaa area oe on | a eT 1 
|Routine in which|Phase in which] 


| Message |message number |message number | 


| number [is generated jis generated | 
--------- 4-~--------------4--------------f 
| IEKOO2I | XCLASS | | 
-----~--- }~--~---~-~------ | 
| IEKOO03I1 | PERLOG | | 
-<-------- ce oa ea aaa I 
} IEKOO4I | PERLOG | | 
[--------- }---------------- | 
| IEKOO5I | RTPROT | | 
<--<------ $-~------~-------- i 
| IEKOO6I | LABTLU | | 
}--------- }--------—------ 
| IEKOO7I | MINSLS | | 
}-----—---}~---—-~-—--~--- | 
| IEKOO8I | LITCON | | 
~-------- }---------------- | 
| IEKOO9I | LITCON { { 
Se SSS= 4----------~------| | 
| IEKO10I1 | LITCON | [ 
--------- 4+-----—--~-—----~---] PHASE 10 | 
| IEKO111 | CSORN | | 
—---+-+-- ¢----------------f | 
{ IEKO12I1 | CSORN | | 
aaa etEnEEE +----~-------~---| | 
| IEKO131 | PUTX i | 
-—------—- 1 Sica Ce a a | 
{| IEKO14I | INTCON | | 
SSS te--- =~ | 
| IEKO16I | XGO | | 
--------- ----------~-——-+} | 
| IEKO0171 | XGO | | 
--------- 4----------------] | 
| IEKO18I | XGO | | 
~-------- }----------------{ | 
| IEK019I1 | XGO | | 
~-------- ~--------------- | 
| IEKO20I | XGO | | 
------==- ----------------4 | 
{| IEKO21iI | XGO | | 
~--~----- $-----=----------1 | 
| IEKO22T1 | XGO | | 
[ pee eee OE 5 Te lye tet he Rn ee rey oesas Pat See ed dj 


APPENDIX H: DIAGNOSTIC MESSAGES 


of the above referenced publication). This 
value is in hexadecimal and indicates which 
phase of the compiler was in control when 
the error occurred. The value for m may be 
any one of the following: 





m Phase 

1 Phase 10 

2 Phase 15 (STALL) 

4 Phase 15 (PHAZ15) 

8 Phase 15 (CORAL) 
10 Phase 20 
20 Phase 25 
40 Phase 30 

foS=ts- T= a sma ao Fats TSS 1 
| IEKO27I | XASGN | | 
}-------~- }~--------------- { | 
| IEKO28I | XASGN | | 
}---~-~~-~ f-~~--~~-~---~——~ 1 | 
| IEKO29I | RTPROT | | 
}--~~----- }-----~---------- 1 | 
| IEKO30I | XDO | | 
po--~—~~—— f---~-~=--------- { | 
{| IEKO31I | CDOPAR | | 
}--~--~--- }--~--~------~--- { | 
{| IEKO32I | XARITH | | 
}-~-----—- {---~-~~-----—--- { | 
J] IEKO331I | XARITH | | 
}--------- }---------------- { | 
| IEKO34I | DSPTCH | | 
{--~—-~-—~ fawn nnn nnn { | 
| IEKO36I | DSPTCH | | 
poses foaaa nanan { | 
{| IEKO371 | XASF | | 
}~--~--~-- fonan nanan { | 
{ IEKO4OI | PERLOG | | 
-}--------- 4--~--~+------~----- 4 PHASE 10 | 
| IEKO41iI | PERLOG | | 
}~------~- Jo----=--~- ~~~ { | 
| IEKO43I | COMAST | | 
}-----~--- eu ena : | 
| IEKO44I | COMAST | | 
}--~------ }---------~------ { | 
| IEKO45I | COMAST | | 
p---—-=-== {~--~--+~-~—----- : | 
| IEKO46I | XDIM | | 
}--------- }---------------- 1 | 
| IEKO47I | COMAST | | 
}-~--~--~~ +---------------- { | 
|} IEKO4S8I | XARITH | | 
}--~---~-- }---------------- { | 
| IEKO49TI | LITCON | | 
po-~-—~—~ }---—------------ { | 
|] IEKO50I | RPTROT | | 
}----~---- +~--------~------ { | 
|] ITEKO51I1 | RPTROT | | 
}-----~--~ pomnne nanan { | 
| IEKO52I | DSPTCH | | 
be ee a We oe er Ne 5 ata at arg es ear 4 
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Diagnostic Messages 


Appendix H: 


Por ee oe eS eee ee aes ee We a ee 1 Pare rae Mee een ep gt res op ata Weel ee owe ee ee 1 
| IEK5001 | FORMAT | {| | IEK5551 | GENER, GMAT| 

[--------- }--~------------- { | |--------- }---------------- 1 

| IEK5011 | EXPON | |} | ZEK5601 | GETEXT | 

}--------- }---------------- { | f--------- }---------------- 

| IEK502I | EXPON | | IEK573I | GENER, TXTLAB, | 

}--------- $---------------- { | | | TXTREG | 

| IEK5031 | BLTNFN l (ee fener . een eee . 

sd a pee yes aren ieee ero eet J | | IEK580I | ALTRAN | PHASE 15 
| IEK5051 | PHAZ13 | a, ee i ieee eee Seen renee 4 (PHAZ15) 
beetoe eS fe ee ene a j | | IEK5811 | SUBMLT | 

| IEK506I | ALTRAN | > . heeecoe et eee meee | 

ane dence ease oes 4 |} | IEK583I | TXTREG | 

| IEK5071 | BLTNEN | a eee 1 er nearer | 

bese aeees Peete ee oe { | | IEK584r | MATE | 

| IEK5081 | BLTNFN | bE  ipeeeeeee a2 Paiste es ee { 

eee eee | Game earls ees ee errs | | ZEK585I | FINISH 

| IEK509I | PHAZ15 | a Seen bee mrrevere ee enpaeeryeen Atel le 
bee as boeic eee ee i | | ZEK600I | TOPO 

| IEK510I | ANDOR | |; opesee aes sa eee ae cee | 

aie nents Ae tera te aia | | IEK610I | TOPO | 

| IEK511z | NOT | [| f+ --+---- \ Sage ee ener ee | 

boca oee eee ae eee ee | {| | ZEK631I | GETDIK 

| IEK5121 | FINISH l re ene Piestea leas anes | 

peee oe eee Aiea ea j | | IEK640OI | GETSPC | 

| IEK5151 | RELOPS Po) whet aetea tse Sf a ee 4 PHASE 20 
benep eas Pisce ed aoe. | | | ZEK650I | TOPO r 

| IEK5201 | ALTRAN | | pee sere eee j 

ae | tener eon | | IEK660I | TOPO | 

| IEK5211 | ALTRAN | SPHASESTS-- |) “pees--22== Petes ae ee | 

ean eee er dee tee nec J (PHAZ15) | | ZEK670I | BAKT | 

| IEK522I | ALTRAN | rt acerca t Ipepaeenrey een ee eres eoe j 

bones ae fi sete ees | | | IBK6711 | BIZX l 

| IEK5231 | ALTRAN | a ae eae r 

ee nee Miata hee aes Seto r | | ZEK680I | RELCOR | 

| IEK5241 | ALTRAN | a eee terete ae er ee Ee eet rent Penn 
beecetoeas fete ee ee F | | IEK7101 | FORMAT 

| IEK5251 | ALTRAN | — ee Yee ereeese ee | 

cae eee tae eee ee | | | IEK720z | FORMAT l 

| IEK5261 | RELOPS | f?, . eeeete sce eae een aera ee | 

beet i ee ete eee eee j | | IEK7301 | FORMAT | 

| IEK5271 | ANDOR | fo bee eos eee ee eee | 

foeeoaee as Wedewue etek eee J | | ZEK740I | FORMAT | 

| IEK528I | BLTNFN | ae See Eee ee eee ee eee 4 PHASE 25 
eee Aid ec ee alate J {| | IEK7502 | FORMAT 

| IEK529I | XPARAM a eee Fost ian oe aceS are { 

Wopeaeeee i poeee ees eee none J | | IEK760I | FORMAT | 

| IEK5301 | SUBADD | | bese soe fe ae ees 4 

babel es a a ee ae | | | IEK7701 | FORMAT l 

| IEK5341 | ALTRAN | a or ; eee eee ee ee | 

Legere Pee ete eee | | | IEK780I | NADOUT | 

| IEK5411 | DFUNCT | a eae a ener er ea 
a yale eee ne eae 4 {| | IEK999I | IEKP30 l 

| IEK542z | ALTRAN | | eters es oases eer re { PHASE 30 
becesaceas 1 eee aera ere | | ZEKOO1I | IEKP30 | 

| IEK550I | ALTRAN, XPARM | |’ eee eaee dese soe eesses deeeeeeat Sas aee 
Gee he OG a es ee Jd 
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Included in the FORTRAN IV (H) compiler 
are two optional facilities which provide 
output that can be used to analyze compiler 
operation and to diagnose compiler malfunc- 
tion. These two facilities are TRACE and 
DUMP. 


TRACE 


The TRACE facility can be used to trace 
the creation of and the modifications made 
to the information table and intermediate 
text, and to provide various other types of 
diagnostic information. This facility is 
activated by the inclusion of the TRACE 
keyword parameter in the PARM field of the 
EXEC statement used to invoke the compiler. 
The format of this parameter is 


TRACE=value 


where: 
value may be either: (1) any one of 
the basic keyword values appearing in 
Table 57, or (2) any value that is 
formed by adding two or more of these 
basic keyword values. 


The type of diagnostic information to be 
provided by the compiler for a given compi- 
lation or batch of compilations is deter- 
mined according to the value specified for 
the TRACE keyword. Table 57 defines the 
type of diagnostic information produced for 
each of the basic keyword values for the 
TRACE keyword. If one of these values is 
specified, the corresponding information is 
provided by the compiler. For example, if 
the basic keyword value of 4 is specified, 
the compiler generates PHAZ15 diagnostic 
information. 


If the value given to the TRACE keyword 
is the sum of two or more basic keyword 
values, then the compiler will produce the 
type of information that corresponds to 
each basic keyword value that was added to 
form that value. For example, if the value 
12 (the sum of basic keyword values 4 and 
8) is specified, the compiler will generate 
both PHAZ15 diagnostic information and 
CORAL diagnostic information. 


Appendix I: 


APPENDIX I: THE TRACE AND DUMP FACILITIES 


Table 57. Basic TRACE Keyword Values ana 


Output Produced 
ancl nar aad De een 7 
[Basic | | 
|Keyword|Output Produced . | 
{Values | | 


| 2 {Printout of the information table| 
| jas it appears after the execution] 
! Jof STALL in Phase 15 | 


| 
I 
| 
| 
| 
! 
I 
| 

+ 
| 
{ 
| 
| 
| 
{ 
! 
| 
I 
| 
| 
! 
| 
| 
| 
| 
| 
| 
| 
| 
| 
! 
! 
| 
| 
| 
| 
! 
! 
| 
| 
| 
! 

_ 


64 |Printout of: | 
1. Intermediate text and infor-| 
mation table as they appear] 
after the execution of Pnase| 
10. | 
2. Information table as it| 
appears after the execution| 
of STALL in Phase 15. | 
3. Intermediate text and infor-| 
mation table as they appear] 
after the execution of | 
PHAZ15 in Phase 15. | 
4. Information table as it| 
appears after the execution| 
of CORAL in Phase 15. | 
5. Intermediate text as it| 
appears after the execution| 
of Phase 20. | 


cea ce me eee ee eee a me ea meee me ee cee ee cee en ee 


128 |Block size information for each] 
| Jtext block (Phase 20) | 
}------- }--------------------------------- { 
| 256 |Diagnostic information from the| 
| | register assignment routines | 
| | (Phase 20) | 


| 
| 
| 
| 
] 
| 
| 
| 
| 
I 
I 
| 
| 
| 
| 
| 
| 
| 
' 
! 
| 
| 
| 
! 
| 
I 
| 
| 
| 
| 
| 
| 
| 
abe 


1 
| 512 |Diagnostic information from the] 
| jtext optimization routines (Phase | 
| |20) 7. 
{ 1024 |Busy-on-exit information for each| 
| jtext block (Phase 20) | 


] 2048 |Additional diagnostic information | 
| jfrom the register assignment rou- | 
| {tines (Phase 20) | 
| 4096 |Printout of intermediate text and| 
| Jinformation table before and| 
| jafter the execution of Phase 20 | 
PosS2s55 Bea ae See ee ee J 
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DUMP 

The dump facility, if activated, wiil 
cause abnormal termination of compiler 
processing if a program interrupt occurs 
during compilation. It will aiso cause the 
main storage areas occupied by the compil- 
er, aS well aS any associated data and 
system control blocks to be recorded on an 
external storage device. The dump facility 
is activated by including in the compile 
step of tne job: (1) the word DUMP as a 
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parameter in the PARM field of the EXEC 
statement, and (2) a SYSABEND data defini- 
tion (DD) statement. 


Note: If the DUMP parameter is specified 
but tne SYSABEND DD statement is omitted, 
abnormal termination, accompanied by an 
indicative dump, will occur if a program 
interrupt is encountered. If a program 
interrupt occurs and the DUMP parameter is 
not specified, the current compilation wiil 
be deleted and the next will be attempted. 


Absolute constant 
definition of 56 
Adcon table 
generation of ESD, TXT, and RLD records 
for 65 
in relative address assignment 35 
reserving entries within 62 
Adcon variable 38 
Address assignment 
(see relative address assignment) 
Address constant 
in relative address assignment 35 
Adjective code 
in intermediate text 144-145 
Allocation 
of storage for compiler 
Arithmetic expressions 
reordering of 26-27 
special processing of 
Arithmetic subroutines 21-22 
Arithmetic translation 25-29 
Arithmetic type interruptions 
object-time processing of 188 
Array I/O list items 
object-time processing of 181-184 
Arrays 
address computation for elements of 213 
as parameters 213 
relative address assignment for 36-38 
statement number/array table entry for 


15-17 


27-29 


130-131 
Assignment 
of registers 40-46, 60-61 
of relative addresses 35-38 
Back dominator 
definition of 48 
determination of 49-50 


BACKSPACE statement 
object-time implementation of 
187-188,194 
Back target 
definition of 48 
determination of 50-51. 
Backward connection information 
gathering of 33-34 
Backward movement 
example of 175 
processing performed during 57-59 
Base value, for equivalence group 
definition of 37 
Base variable 38 
Basic direct access method 
object-time use of 179-180 
Basic register.assignment 40-43 
Basic sequential access method 
compile-time use of 17 
object-time use of 179-180 
BDAM 
(see basic direct access method) 
Bit strip arrays 
composition of 67 


INDEX 


format of 165-171 

use of 67-68 
Bit tables, text optimization 137-138 
Branch table 

chaining in 120,124 

contents of 133 

entry formats 133-135 

modifications to 134-135 
Branching optimization 46-47,61 
BSAM 

(see basic sequential access method) 
BSP macro-instruction 

object-time use of 195 
Buffers 

object-time use of 191-194,196-199 
Busy-oOn-exit information 51-53 


CALL statements 
generation of calling sequences for 67 
Chains 
construction of 120-121 
definition of 120 
in information table 120 
in intermediate text 143 
CHECH macro-instruction 
object-time use of 193,195,199 
Classification 
process of 117 
Classification tabies 
format of 117-120 
use of 117 
CLOSE macro-instruction 
object-time use of 194 
CMAJOR 
construction of 33-34 
Code generation 67-69 
Common blocks 
common table entries for 131 
Common expression elimination 
example of 173 
processing performed during 55-56 
Common table 
chaining in 120,122-123 
contents of 131 
entry formats 131-132 
modifications to 131-132 
Communication table 
format of 118 
use of 117 
Commutative operations 
processing of 28 
Compilation 
deletion of 18 
Compiler 
initialization of 14 
input/output data flow of 11-12 
organization of 11-13 
purpose of 11 
relation to operating system 11 
structure 12, 214-220 
termination of processing 18 
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Literal data 

literal table entry for 133 
Literal table 

chaining in 120,123 

contents of 133 

entry formats 133 

modifications to 133 
LMVF 

(see loop composite matrixes) 
LMVS 

(see loop composite matrices) 
LMVX 

(see loop composite matrixes 
Local assignment 

in full register assignment 
Location counter 

use in building object module 61 

use in assigning relative addresses 35 
Logical expressions 

processing of 29 
Loop composite matrixes 
Loop numbers 

assigning of 51 
Loops 

identification of 51 

ordering of 51 

selection of 53-54 


43-45 


54-55 


Main program entry coding 64 
Mask, program interruption 

object-time setting of 188 
MBM bit table 137-138 
MBR bit table 137-138 
Message pointer table 

use of 70 

format of 141 
MFM bit table 137-138 
Mode/type field 

in dictionary 125 


in intermediate text 144,154,155 
Movement 
forward 
(see forward movement) 
backward 


(see backward movement) 
MSM bit table 137-138 
MVD table 30,51-53 
MVF field 29-30 
MVS field 29-30 


MVU bit table 137-138 
MVV bit table 137-138 
MVW bit table 137-138 


MVX field 29-31,51-53 
MXM bit table 137-138 


Namelist dictionaries 
construction of 63-64 
format of entries in 140-141 
object-time use of 187 
Namelist text 
conversion of 
example of 148 
Negative address constant 37 
Non-optimized path 
processing performed within 38-39 
Normal text 
example of 146 


63-64 
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Object module 61 
Object program 
(see object module) 
Object-time I/O errors 
processing of 194,199,207 
Object-time library subprograms 
(see library subprograms) 
Object-time namelist dictionaries 
(see namelist dictionaries) 
Offset 23,24 
Opening 
of data control blocks at object-time 
192-193,197-198 
OPEN macro-instruction 
object-time use of 181,193 
Operands 
source statement scan Of 20-22 
Operators 
source statement scan of 20-22 
Overlay structure 
of compiler 214-220 


Parameter processing 14 
PAUSE statement 
object-time implementation of 188 
Preparatory subroutine 19-20 
Primary path 
definition of 50 
Prologue 65-66 
Pushdown table 26-27 
READ macro-instruction 
object-time use of 181-185,192-193,198 
READ statement, direct access 
object-time implementation of 
179-186,197-199, 209 
READ statement, sequential access 
object-time implementation of 
179-187,192-193, 206 
Reduction, strength 
(see strength reduction) 
Register array 67-68 
Register assignment 
Register assignment tables 
Relative address assignment 
for arrays 36 
for common variables and arrays 37 
for constants 36 
for equivalence variables and arrays not 
in common 36-37 
for Hollerith character strings 36 
for variables 36 
for variables and arrays equivalenced 
into common 37-38 
Relocation dictionary 70 
Reordering of intermediate text 
for arithmetic expressions 
Reserved register addresses 47 
Reserved registers 47 
RETURN statement 
processing of 69 
REWIND statement 
object-time implementation of 
RLD 
(see relocation dictionary) 
RLD record 
contents of 70 


40-46,60-61 
139-140 


26-27 


187,194 


RMAJOR 
construction of 31-32 


Scan 
of source statements 20-22 
Sequential access I/O data 
management interface 
(see IHCFIOSH library subprogram) 
SF 
(see statement function) 
SF skeleton text 
construction of 21-22 
example of 149 
Simple store 
definition of 58 
Simple store elimination 
example of 176 
processing performed during 58 
Skeleton arrays 
composition of 67 
format of 165-171 
use of 67-69 
Source module listing 19 
Source statement scan 20-22 
Span 
definition of 213 
SPIE macro-instruction 
object-time use of 188 
Standard text 
examples of 156-164 
format of 154-155 
Statement functions 
processing of 21-22,29 
text for 149 
Statement number chain 
reordering of 32 
Statement number/array table 
chaining in 120,122 
contents of 128 
entry formats 128-131 
modifications to 129-130 
Statement numbers 
asSigning address constants to 66 
reserving adcon table space for 62 
statement number/array table entries 
for 128-130 
text for 151-154 
Statement number text 
format of 151-154 
construction of 25 
Statement processing, compile-time 
arithmetic 21,25-29,77 
CALL 21,22,67,77 
COMMON 20, 23,37-38,77 
DATA 34-35,38,65, 77,147,150 
DIMENSION 20,77 
DO 77,177 
END 69,77 
ENTRY 66-67,77 
EQUIVALENCE 20, 24,36-38,77 
EXTERNAL 20,77 
FORMAT 63,77,149 
GO TO 62,65,69,7 
IMPLICIT 20 
keyword 20-21,77 
NAMELIST 63-64,77,148 
READ/WRITE 20,21,67,77 


RETURN 69,77 
statement function 21-22,29,77,149 
Statement processing, object-time 
BACKSPACE 187-188,194 
DEFINE FILE 197,208 
END FILE 187,194 
FIND 180-181,198-199 
FORMAT 181-183 
PAUSE 188 
READ, direct access 179-186,197-199,209 
READ, sequential access not using 
NAMELIST 179-186,192-193, 206 
READ, Sequential access using NAMELIST 
187,192-193 . 
REWIND 187,194 
STOP 188 
WRITE, direct access 
179-186,197-199, 209 
WRITE, sequential access not using 
NAMELIST 179-186,192-193,206 
WRITE, sequential access using NAMELIST 
187,192-193 
Status 
in code generation 67-68 
in intermediate text 155-156 
in register assignment 40 
STOP statement 
object-time implementation of 188 
Storage allocation 
for compiler 15-17 
Storage map 
production of 38 
Stored constant 
definition of 56 
Strength reduction 
example of 177-178 
processing performed during 59-60 
Structural determination 48-51 
Structure 
(see overlay structure) 
Structured source listing 19-20,53 
Subprogram main entry coding 64 
Subprogram references 
processing of 28-29 
Subprogram secondary entry coding 64-65 
Subprogram table 
use of 28-29,135 
format of 136 
Subscript expressions 
computation of 213 
Subscripts 
processing of 28 
Substitute ddnames 14 


Table building 
for full register assignment 44-45 
Tables 
adcon 35,62,65,70 
branch 133-135 
classification 117,119-120 
common 131-132 
communication 117-118 
diagnostic message 141 
dictionary 124-128 
error 141 
information 120-135 
keyword 117,119-120 
keyword pointer 117,119 
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literal 133 
message pointer 141 
register assignment 139-140 
statement number/array 128-131 
subprogram 28-29,135-136 
text optimization bit 137-138 
unit assignment 190-191,196 
Termination 
of compiler processing 18 
of load module execution 188 
Text 
(see intermediate text) 
Text block 
definition of 25 
Text blocking 25 
Text conversion 66-69 
Text information 
composition of 61 
construction of 61-62 
Text optimization 
bit tables 137-138 
examples of 173-178 
processing performed during 55-60 
Text updating 
in full register assignment 46 
Translation, arithmetic 25-29 
Trace facility 225 
TXT 
(see text information) 
TXT records 
contents of 61 
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Unary minuses 
processing of 28 
Unit assignment table 
in IHCDIOSH 196 
in IHCFIOSH 190-191 
Unit blocks 
in IHCDIOSH 194-196 
in IHCFIOSH 189-190 
Utility subroutines 
of phase 10 22 


Variables 
dictionary entries for 124-126 
point of definition for 43 
relative address assignment for 36-38 
reserving space in object module for 63 


WRITE macro-instruction 
object-time use of 183,184,193,199 
WRITE statement, direct access 
object-time implementation of 
179-186,197-199, 209 
WRITE statement, sequential access 
object-time implementation of 
179-187,192-193, 206 
Write-to-operator routines 
in IHCFCOMH 188 
WTO macro-instruction 
object-time use of 188 
WTOR macro-instruction 
object-time use of 188 
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Forward connection information 
gathering of 32-33 
Forward movement 
example of 174 
processing performed during 57 
Forward target 54 
FREEMAIN macro-instruction 
object-time of 199 
FREEPOOL macro-instruction 
object-time use of 194 
Full register assignment 43-46,60-61 
GETMAIN macro-instruction 
Oobject-time use of 189,195 
Global assignment 
in full register assignment: 43-46,60-61 
Head, for equivalence group 
definition of 24 
Hollerith character strings 
relative address assignment for 36 


IFUNTB 
(see subprogram table) 
IHCDBUG library subprogram 179,200-201 
IHCDIOSH library subprogram 
buffering scheme of 196-197 
communication with control program 197 
file definition section of 197 
file initialization section of 197-198 
functions of 179 
I/O error processing of 199,207 
overall logic of 208-209 
read section of 198-199 
tables and blocks used in 194-196 
termination section 199 
unit assignment table 196 
unit blocks of 194-196 
write section of 199 
IHCFCOMH library subprogram 
closing section of 184 
conversion routines of 189 
device manipulation routines of 187-188 
format scan of 181,183 
functions of 179 
generation of calling sequences to 67 
I/O list section of 181-184 
Opening section of 181 
read/write routines of 
utility routines of 188 
write-to-operator routines of 188 
IHCFCVTH library subprogram 189 
IHCFIOSH library subprogram 
buffering scheme of 191 
closing section of 194 
communication with control program 
191-192 
device manipulation section of 194 
error processing of 194 
functions of 179 
initialization section of 192-193 
I/O error processing of 194 
Overall logic of 206 
processing for 1403 printer 192-194 
read section of 193 
write section of 193 
unit assignment table in 190-191 
unit blocks in 189-190 


180-187 


IHCIBERH library subprogram 179,199 
IHCNAMEL library subprogram 179,187 
Information table 
chains within 120-121 
components 120 
operation of chains within 121-124 
Initialization Instructions 64-65 
Initialization section 
in IHCFIOSH 192-193 
In-line routine references 
processing of 28-29 
Input/output buffers 
(see buffers) 
Input/output data sets 
(see data sets) 
Input/output list items 
object-time processing of 181-184 
Input/output requests 
compile-time processing of 18 
format of 17 
Input/output statements 
generation of calling sequences for 67 
object-time implementation of 179-211 
Intermediate-optimized path 
processing performed within 39-40 
Intermediate text 
chaining in 143 
types of 143,150 
entry formats 144,150-155 
examples of 146-149,157-164 
Internal statement number 
compiler assigning of 20 
Interruptions, arithmetic 
object-time processing of 188 
I/O library subprograms 
(see library subprograms) 
I/O list items 
(see input/output list items) 
I/O recovery procedure 
object-time 207 
I/O requests 
(see input/output requests) 
I/O statements 
(see input/output statements) 
ISN 
(see internal statement number) 


Keyword pointer table 
format of 119 
use of 117 
Keyword subroutines 
Keyword table 
format of 119-120 
use of 117 


20-21 


Library subprograms 
IHCDBUG 200-201 


IHCDIOSH 194-199 
IHCFCOMH 179-188 
IHCFCVTH 189 

ITHCFIOSH 189-194 


IHCIBERH 199 

IHCNAMEL 187 
List items 

(see input/output list items) 
Literal constant 

literal table entry for 133 
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Literal data 

literal table entry for 133 
Literal table 

chaining in 120,123 

contents of 133 

entry formats 133 

modifications to 133 
LMVF 
(see loop composite matrixes) 
LMVS 

(see loop composite matrices) 
LMVX 

(see loop composite matrixes 
Local assignment 

in full register assignment 
Location counter 

use in building object module 61 

use in assigning relative addresses 35 
Logical expressions 

processing of 29 
Loop composite matrixes 
Loop numbers 

assigning of 51 
Loops 

identification of 51 

ordering of 51 

selection of 53-54 


43-45 


54-55 


Main program entry coding 64 
Mask, program interruption 

object-time setting of 188 
MBM bit table 137-138 
MBR bit table 137-138 
Message pointer table 

use of 70 

format of 141 
MFM bit table 137-138 
Mode/type field 

in dictionary 125 

in intermediate text 144,154,155 
Movement 

forward 

(see forward movement) 
backward 
(see backward movement) 

MSM bit table 137-138 
MVD table 30,51-53 
MVF field 29-30 
MVS field 29-30 
MVU bit table 137-138 
MVV bit table 137-138 
MVW bit table 137-138 
MVX field 29-31,51-53 
MXM bit table 137-138 


Namelist dictionaries 
construction of 63-64 
format of entries in 140-141 
object~time use of 187 
Namelist text 
conversion of 
example of 148 
Negative address constant 37 
Non-optimized path 
processing performed within 38-39 
Normal text 
example of 146 
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Object module 61 
Object program 
(see object module) 
Object-time I/O errors 
processing of 194,199,207 
Object-time library subprograms 
(see library subprograms) 
Object-time namelist dictionaries 
(see namelist dictionaries) 
Offset 23,24 
Opening 
of data control blocks at object-time 
192-193,197-198 
OPEN macro-instruction 
object-time use of 181,193 
Operands 
source statement scan of 20-22 
Operators 
source statement scan of 20-22 
Overlay structure 
of compiler 214-220 


Parameter processing 14 
PAUSE statement 
object-time implementation of 188 
Preparatory subroutine 19-20 
Primary path 
definition of 50 
Prologue 65-66 
Pushdown table 26-27 
READ macro-instruction 
object-time use of 181-185,192-193,198 
READ statement, direct access 
object-time implementation of 
179-186,197-199, 209 
READ statement, Sequential access 
object-time implementation of 
179-187,192-193, 206 
Reduction, strength 
(see strength reduction) 
Register array 67-68 
Register assignment 
Register assignment tables 
Relative address assignment 
for arrays 36 
for common variables and arrays 37 
for constants 36 
for equivalence variables and arrays not 
in common 36-37 
for Hollerith character strings 36 
for variables 36 
for variables and arrays equivalence 
into common 37-38 
Relocation dictionary 70 
Reordering of intermediate text 
for arithmetic expressions 
Reserved register addresses 47 
Reserved registers 47 
RETURN statement 
processing of 69 
REWIND statement 
object-time implementation of 187,194 
RLD 
(see relocation dictionary) 
RLD record 
contents of 70 


40-46,60-61 
139-140 


26-27 


Absolute constant 
definition of 56 
Adcon table 
generation of ESD, TXT, and RLD records 
for 65 
in relative address assignment 35 
reserving entries within 62 
Adcon variable 38 
Address assignment 
(see relative address assignment) 
Address constant 
in relative address assignment 35 
Adjective code 
in intermediate text 
Allocation 
of storage for compiler 15-17 
Arithmetic expressions 
reordering of 26-27 
special processing of 27-29 
Arithmetic subroutines 21-22 
Arithmetic translation 25-29 
Arithmetic type interruptions 
object-time processing of 188 
Array I/O list items 
object-time processing of 181-184 
Arrays 
address computation for elements of 213 
aS parameters 213 
relative address assignment for 36-38 
statement number/array table entry for 


144-145 


130-131 
Assignment 
of registers 40-46,60-61 
of relative addresses 35-38 
Back dominator 
definition of 48 
determination of 49-50 


BACKSPACE statement 
object-time implementation of 
187-188,194 
Back target 
definition of 48 
determination of 50-51. 
Backward connection information 
gathering of 33-34 
Backward movement 
example of 175 
processing performed during 57-59 
Base value, for equivalence group 
definition of 37 
Base variable 38 : 

Basic direct access method 
Object-time use of 179-180 
Basic register.assignment 40-43 

Basic sequential access method 
compile-time use of 17 
object-time use of 179-180 

BDAM 
(see basic direct access method) 

Bit strip arrays 
composition of 67 


INDEX 


format of 165-171 

use of 67-68 
Bit tables, text optimization 137-138 
Branch table 

chaining in 120,124 

contents of 133 

entry formats 133-135 

modifications to 134-135 
Branching optimization 46-47,61 
BSAM 

(see basic sequential access method) 
BSP macro-instruction 

object-time use of 195 
Buffers 

object-time use of 191-194,196-199 
Busy-on-exit information 51-53 


CALL statements 
generation of calling sequences for 67 
Chains 
construction of 120-121 
definition of 120 
in information table 120 
in intermediate text 143 
CHECH macro-instruction 
object-time use of 193,195,199 
Classification 
process of 117 
Classification tabies 
format of 117-120 
use of 117 
CLOSE macro-instruction 
object-time use of 194 
CMAJOR 
construction of 33-34 
Code generation 67-69 
Common blocks 
common table entries for 131 
Common expression elimination 
example of 173 
processing performed during 55-56 
Common table 
chaining in 120,122-123 
contents of 131 
entry formats 131-132 
modifications to 131-132 
Communication table 
format of 118 
use of 117 
Commutative operations 
processing of 28 
Compilation 
deletion of 18 
Compiler 
initialization of 14 
input/output data flow of 11-12 
organization of 11-13 
purpose of 11 
relation to operating system 11 
structure 12, 214-220 
termination of processing 18 
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Complete-optimized path 
processing performed within 
Complex expressions 
processing of 28 
Computed GO TO statements 
compile-time processing of 
Constants 
absorption of 213 
dictionary entries for 127-128 
generation of TXT records for 62-63 
relative address assignment for 36 
Constant/variable usage information 
gathering of 29-31 
Control block, data 
(see data control block) 
Control block, data event 
(see data event control block) 
Control codes 
(see format codes) 
Conversion codes 
(see format codes) 
Conversion routines 
in IHCFCOMH i189 
Counter, location 
(see location counter) 


39-40 


62,66,69 


Data control block i190 
Data control block skeleton section 
in unit biock 190 
Data event control block 190 
Data event control block skeleton section 
in unit block 190 
Data set reference numbers 
object-time creation of unit blocks for 
189,194 
Data sets 
object-time initialization of 
192-193,197-198 
Data text 
example of 147 
final processing of 65 
format of 150 
rechaining of 38 
translation of 34-35 
DCB 
(see data control block) 
DCB skeleton section 
(see data control block skeleton 
section) 
Ddnames, substitute 14 
DECB 
(see data event control block) 
DECB skeleton section 
(see data event control block skeleton 
section) 
Default values 
object-time insertion of into DCB 
skeletons 191 
DEFINE FILE statement 
object-time processing of 197,208 
Definition point 
for a variable ‘43 
Depth number 
determination of 
Device manipulation 
object-time routines for 187-188,195 
Diagnostic messages 221-224 
Diagnostic message tables 141 


50-51 
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Dictionary 
chaining in 120,121-122 
contents of 124 
entry formats 124-128 
modification to 125-128 
Dictionary entries 
rechaining of 23 
Dimension entry : 
in statement number/array table 
Dimension factor 
definition of 213 
Direct access I/O data management 
interface 
(see IHCDIOSH library subprogram) 
Directory array 67 
Dispatcher subroutine 19 
Displacement 
in relative address assignment 35 
Displacement field 
in intermediate text 154 
DSRN 
(see data set reference numbers) 
Dump facility 226 


130-131 


Elimination 

of common expression 

(see common expression elimination) 
of simple stores 
(see simple store elimination) 

END statement 

processing of 69 
END FILE statement 

object-time implementation 
ENTRY statement 

processing of 66-67 
Epilogue 65-66 
Equivalence groups 

common table entries for 
Equivalence head 24 
Equivalence variables 

common table entries for 132 
Error level code 70-71 
Error messages 

generation of 70 
Errors 

object-time processing of 188,194,199 
Error table 

format of 141 

use of 70 

construction of 70 
ESD 

(see external symbol dictionary) 
ESD record 

contents of 70 
External symbol dictionary 70 


187,195 


131-132 


FIND statement 
object-time processing of 179-180,198 
Forcing strength 26-27 
Format codes 
control 181-183 
conversion 181-183,189 
FORMAT intermediate text 
example of 149 
object-time scan of translated form 
181,183 
translation of 63 


